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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards" , which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Satellite Earth Stations and 
Systems (SES). 

The contents of the present document are subject to continuing work within TC-SES and may change following formal 
TC-SES approval. Should TC-SES modify the contents of the present document it will then be republished by ETSI 
with an identifying change of release date and an increase in version number as follows: 

Version 3.m.n 

where: 

• The third digit (n) is incremented when editorial only changes have been incorporated in the specification; 

• The second digit (m) is incremented for all other types of changes, i.e., technical enhancements, corrections, 
updates, etc. 

The present document is part 5, sub-part 1 of a multi-part deliverable covering the GEO-Mobile Radio Interface 
Specifications (Release 3); Third Generation Satellite Packet Radio Service, as identified below: 

Part 1: "General specifications": 

Part 2: "Service specifications"; 

Part 3: "Network specifications"; 

Part 4: "Radio interface protocol specifications"; 

Sub-part 1: "Mobile Earth Station-Gateway Station System (MES-GSS) Interface; GMR-1 04.001"; 

Sub-part 2: "GMR-1 SatelUte Network Access Reference Configuration; GMR-1 04.002"; 

Sub-part 3: "Channel Structures and Access Capabilities; GMR-1 04.003"; 

Sub-part 4: "Layer 1 General Requirements; GMR-1 3G 44.004"; 

Sub-part 5: "Data Link Layer General Aspects; GMR-1 04.005"; 

Sub-part 6: "Mobile earth Station-Gateway Station Interface Data Link Layer Specifications; 
GMR-1 04.006"; 

Sub-part 7: "Mobile Radio Interface Signalling Layer 3 General Aspects; GMR-1 3G 24.007"; 

Sub-part 8: "Mobile Radio Interface Layer 3 Specifications; GMR-1 3G 44.008"; 

Sub-part 9: "Performance Requirements on the Mobile Radio Interface; GMR-1 04.013"; 

Sub-part 10: "Rate Adaptation on the Access Terminal -Gateway Station Subsystem (MES-GSS) Interface; 
GMR-1 04.021"; 
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Sub-part 1 1 : "Radio Link Protocol (RLP) for Data Services; GMR-1 04.022"; 

Sub-part 12: "Mobile Earth Station (MES) - Base Station System (BSS) interface; Radio Link 
Control/Medium Access Control (RLC/MAC) protocol; GMR-1 3G 44.060"; 

Sub-part 13: "Radio Resource Control (RRC) protocol; lu Mode; GMR-1 3G 44.1 18"; 

Sub-part 14: "Mobile Earth Station (MES) - Base Station System (BSS) interface; Radio Link 

Control/Medium Access Control (RLC/MAC) protocol; lu Mode; GMR-1 3G 44.160"; 

Sub-part 15: "Packet Data Convergence Protocol (PDCP) specification; GMR-1 3G 25.323"; 

Part 5: "Radio interface physical layer specifications"; 

Part 6: "Speech coding specifications"; 

Part 7: "Terminal adaptor specifications". 
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Introduction 



GMR stands for GEO (Geostationary Earth Orbit) Mobile Radio interface, which is used for Mobile Satellite 
Services (MSS) utilizing geostationary satellite(s). GMR is derived from the terrestrial digital cellular standard GSM 
and supports access to GSM core networks. 

The present document is part of the GMR Release 3 specifications. Release 3 specifications are identified in the title 
and can also be identified by the version number: 

• Release 1 specifications have a GMR 1 prefix in the title and a version number starting with "1" (Vl.x.x). 

• Release 2 specifications have a GMPRS 1 prefix in the title and a version number starting with "2" (V2.x.x). 

• Release 3 specifications have a GMR-1 3G prefix in the title and a version number starting with "3" (V3.x.x). 

The GMR release 1 specifications introduce the GEO-Mobile Radio interface specifications for circuit mode Mobile 
Satellite Services (MSS) utilizing geostationary satellite(s). GMR release 1 is derived from the terrestrial digital cellular 
standard GSM (phase 2) and it supports access to GSM core networks. 

The GMR release 2 specifications add packet mode services to GMR release 1 . The GMR release 2 specifications 
introduce the GEO-Mobile Packet Radio Service (GMPRS). GMPRS is derived from the terrestrial digital cellular 
standard GPRS (included in GSM Phase 2+) and it supports access to GSM/GPRS core networks. 

The GMR release 3 specifications evolve packet mode services of GMR release 2 to 3rd generation UMTS compatible 
services. The GMR release 3 specifications introduce the GEO-Mobile Radio Third Generation (GMR-1 3G) service. 
Where applicable, GMR-1 3G is derived from the terrestrial digital cellular standard 3GPP and it supports access to 
3GPP core networks. 

Due to the differences between terrestrial and satellite channels, some modifications to the GSM or 3GPP standard are 
necessary. Some GSM and 3GPP specifications are directly applicable, whereas others are applicable with 
modifications. Similarly, some GSM and 3GPP specifications do not apply, while some GMR specifications have no 
corresponding GSM or 3GPP specification. 

Since GMR is derived from GSM and 3GPP, the organization of the GMR specifications closely follows that of GSM 
or 3GPP as appropriate. The GMR numbers have been designed to correspond to the GSM and 3GPP numbering 
system. All GMR specifications are allocated a unique GMR number. This GMR number has a different prefix for 
Release 2 and Release 3 specifications as follows: 

• Release 1: GMR-n XX. zyy 

• Release 2: GMPRS-n xx.zyy 

• Release 3: GMR-1 3G xx.zyy 



where: 



xx.Oyy (z = 0) is used for GMR specifications that have a corresponding GSM or 3GPP specification. In 
this case, the numbers xx and yy correspond to the GSM or 3GPP numbering scheme. 

xx.2yy (z = 2) is used for GMR specifications that do not correspond to a GSM or 3GPP specification. In 
this case, only the number xx corresponds to the GSM or 3GPP numbering scheme and the number yy is 
allocated by GMR. 

n denotes the first (n = 1) or second (n = 2) family of GMR specifications. 



£75/ 



GMR-1 3G 25.323 9 ETSI TS 101 376-4-15 V3.3.1 (2012-12) 

A GMR system is defined by the combination of a family of GMR specifications and GSM and 3GPP specifications as 
follows: 

• If a GMR specification exists it takes precedence over the corresponding GSM or 3GPP specification (if any). 
This precedence rule applies to any references in the corresponding GSM or 3GPP specifications. 

NOTE: Any references to GSM or 3GPP specifications within the GMR specifications are not subject to this 

precedence rule. For example, a GMR specification may contain specific references to the corresponding 
GSM or 3GPP specification. 

• If a GMR specification does not exist, the corresponding GSM or 3GPP specification may or may not apply. 
The appHcabihty of the GSM and 3GPP specifications are defined in TS 101 376-1-2 [7]. 
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1 Scope 

The present document provides the description of the GMR-1 3G Packet Data Convergence Protocol (PDCP). 

2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly 
refers to the latest version of that document in Release 7 or to the latest version of that document in the latest release 
less than 7. 

In the case of a reference to a GMR-1 3G document, a non-specific reference implicitly refers to the latest version of 
that document in the same Release as the present document. 

[I] ETSI TS 123 060: "Digital cellular telecommunications system (Phase 2h-); Universal Mobile 
Telecommunications System (UMTS); General Packet Radio Service (GPRS); Service 
description; Stage 2 (3GPP TS 23.060 Release 7)". 

[2] ETSI TS 125 331: "Universal Mobile Telecommunications System (UMTS); Radio Resource 

Control (RRC); Protocol specification (3GPP TS 25.331 Release 7)". 

[3] ETSI TS 125 322: "Universal Mobile Telecommunications System (UMTS); Radio Link Control 

(RLC) protocol specification (3GPP TS 25.322 Release 7)". 

[4] IETF RFC 2507: "IP Header Compression". 

[5] IETF RFC 3095: "RObust Header Compression (ROHC): Framework and four profiles: RTP, 

UDP, ESP, and uncompressed". 

[6] ETSI TS 101 376-1-1: "GEO-Mobile Radio Interface Specifications (Release 2) General Packet 

Radio Service; Part 1: General specifications; Sub-part 1: Abbreviations and acronyms; 
GMPRS-1 01.004". 

NOTE: This is a reference to a GMR-1 Release 2 Specification. See the introduction for more details. 

[7] ETSI TS 101 376-1-2: "GEO-Mobile Radio Interface Specifications (Release 3); Third Generation 

Satellite Packet Radio Service; Part 1: General specifications; 
Sub-part 2: Inti'oduction to the GMR-1 family; GMR-1 3G 41.201". 

[8] ITU-T Recommendation V.44 (1 1/2000): "Data compression procedures". 

[9] IETF RFC 768 (August 1980): "User Datagram Protocol". 

[10] IETF RFC 791 (September 1981): "Internet Protocol". 

[II] IETF RFC 3261 (June 2002): "SIP: Session Initiation Protocol". 
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2.2 



Informative references 



The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 



[i.l] 

[i.2] 
[i.3] 



ETSI TS 125 401: "Universal Mobile Telecommunications System (UMTS); UTRAN overall 
description (3GPP TS 25.401 Release 7)". 

IETF RFC 3550: "RTP: A Transport Protocol for Real-Time Apphcations". 

ETSI TR 121 905: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 
Telecommunications System (UMTS); Vocabulary for 3GPP Specifications (3GPP TR 21.905)". 



Definitions and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the terms and definitions given in TR 121 905 [i.3], TS 101 376-1-2 [7] and 
the following apply: 



N-context 

N-context* 

N-context-C 

N-context-C* 

N-context-C-static* 

N-context-D 

N-context-D* 

A^-context-D-static* 

M-context 

M-context* 

M-context-C 

M-context-C* 

M-context-C-static* 

M-context-D 

M-context-D*- 

M-context-D-static* 



M-HC 

M-HCD 
M-HD 

N-HC 

N-HCD 
N-HD 



Refers collectively to both N-context-C and N-context-D 

Refers collectively to both N-context-C* and N-context-D* 

The compression context for downlink in RNC at any given point of time 

The frozen snapshot of the compression context for downlink taken by RNC 

The frozen snapshot of the static part of the compression context for downlink taken by RNC 
The decompression context for uplink in RNC at any given point of time 
The frozen snapshot of the decompression context for uplink taken by RNC 

The frozen snapshot of the static part of the decompression context for upUnk taken by RNC 

Refers collectively to both M-context-C and M-context-D 

Refers collectively to both M-context-C* and M-context-D* 

The compression context for uplink in MES at any given point of time 

The frozen snapshot of the compression context for uplink taken by MES 

The frozen snapshot of the static part of the compression context for uplink taken by MES 
The decompression context for downlink in MES at any given point of time 
The frozen snapshot of the decompression context for downlink taken by MES 

The frozen snapshot of the static part of the decompression context for downlink taken by 

MES 

Entity located in the mobile terminal that performs header compression for uplink (i.e. MES 

PDCP) 

Refers collectively to both M-HC and M-HD 

Entity located in the mobile terminal that performs header decompression for downlink 

(i.e. MES PDCP) 

Entity located in the network that performs header compression for downlink (i.e. RNC 

PDCP) 

Refers collectively to N-HC and N-HD 

Entity located in the network that performs header decompression for uplink (i.e. RNC 

PDCP) 
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3.2 



Abbreviations 



For the purposes of the present document, the abbreviations given in TS 101 376-1-1 [6] and the following apply: 



AS 

CID 

C-SAP 

GMR-1 3GLLA 

HC 

HCL 

HCU 

IETF 

IP 

L2 

MBMS 

M-HC 

M-HCD 

M-HD 

NAS 

N-HC 

N-HCD 

N-HD 

PDCP 

PDU 

PID 

PPP 

RAB 

RB 

RFC 

RLC 

RNC 

RoHC LLA 

ROHC 

RTP 

SDU 

SE-VoIP 

SIP 

TCP 

UDP 

UMTS 

UTRAN 



Access Stratum 

Context Identifier 

Control Service Access Point 

GMR1-3G Lower Layer Assisted 

Header Compression 

Header Compression Lower layer 

Header compression Upper layer 

Internet Engineering Task Force 

Internet Protocol 

Layer 2 (data link layer) 

Multimedia Broadcast Multicast Service 

Mobile Header Compressor 

Mobile Header Compressor/Decompressor 

Mobile Header Decompressor 

Non Access Stratum 

Network Header Compressor 

Network Header Compressor/Decompressor 

Network Header Decompressor 

Packet Data Convergence Protocol 

Protocol Data Unit 

Packet Identifier 

Point-to-Point Protocol 

Radio Access Bearer 

Radio Bearer 

Request for Comments 

Radio Link Control 

Radio Network Controller 

Robust Header Compression Link Layer Assisted 

Robust Header Compression 

Real Time Protocol 

Service Data Unit 

Spectrally Efficient Voice over IP 

Session Initiation Protocol 

Transmission Control Protocol 

User Datagram Protocol 

Universal Mobile Telecommunications System 

UMTS Terrestrial Radio Access Network 



General 



4.1 Objective 

The present document describes the functionality of the GMR-1 3G Packet Data Convergence Protocol (PDCP). 

4.2 Overview on Sublayer Architecture 

Figure 1 shows the model of the PDCP within the radio interface protocol architecture. The PDCP sublayer is defined 
for the PS domain only. 

Every PS domain Radio Access Bearer (RAB) is associated with one Radio Bearer (RB), which in turn, is associated 
with one PDCP entity. Each PDCP entity is associated with one or two (one for each direction) RLC entities depending 
on the RB characteristic (i.e. unidirectional or bidirectional) and RLC mode. The PDCP entities are located in the PDCP 
sublayer. 
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Every PDCP entity uses zero, one or several different header compression and data compression protocols. Each 
individual PDCP entity uses at most one instance of each header compression protocol. Several PDCP entities may be 
defined for a MES with each using the same or a different set of header compression protocols. In this version of the 
specification, the following header compression protocols are supported: 

• RFC 2507 [4] 

• RFC 3095 [5] 

• GMR-1 3G Lower Layer Assisted Header Suppression, which is defined in the present document 

• ITU-T Recommendation V.44 Data Compression [8] 

The PDCP sublayer is configured by the upper layer through the PDCP-C-SAP. 

Radio Bearers 



C-SAP, 







PDCP 
entity 



HC 
Protocol 1 



.PDCP-SAPs . 



O 



HC 
Protocol 2 



PDCP 
entity 



SDU 

numbering 



HC 
Protocol 1 



HC 
Protocol 2 



PDCP 
entity 



HC 
Protocol 1 




TM-SAP 



PDCP-SDU 



O 



PDCP- 
sublayer 



RLC-SDU 



(oXQ>-<:^ 



RLC 



Figure 1 : PDCP Structure 

Figure 1 represents one possible structure for the PDCP sublayer and should not restrict implementation. A PDCP entity 
is mapped either to one AM RLC entity, or one or two UM or TM RLC entities. When a PDCP entity is mapped to two 
UM or TM RLC entities, each RLC entity is used for a different direction. 



Functions 



PDCP provides its services to the NAS at the MES or the relay at the Radio Network Controller (RNC). 
The Packet Data Convergence Protocol shall perform the following functions: 

• Header compression and decompression of IP data streams (e.g. TCP/IP and RTP/UDP/IP headers for IPv4 
and IPv6) at the transmitting and receiving entity, respectively. 

• Header suppression (of RTP/UDP/IP headers) of GMR- 1 3G spectrally efficient VoIP (SE-VoIP) streams. 

• Transfer of user data. This function is used for conveyance of data between users of PDCP services. 
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• Data compression. 

• SRNS Relocation. 

PDCP uses the services provided by the Radio Link Control (RLC) sublayer. 

PDCP supports two kinds of compression, namely header compression and data compression. The header and data 
compressions for an IP packet are applied sequentially. 

On the encoder side, every IP packet will arrive at the data compression entity first. After compressing the transport 
layer payload, the data compression entity attaches the compressed payload to the original Transport/IP header and 
delivers it to the header compression entity. If the payload is not compressed, it will be delivered to the header 
compression entity without any changes. 

On the decoder side, the header decompression will decompress the Transport/IP header only and then delivers it along 
with the compressed or uncompressed payload to the data decompression entity. If the payload is compressed, the data 
decompressor will decompress it and deliver it to the upper layer along with the decompressed header. If the payload is 
not compressed, the data decompressor just passes it to the upper layer. 



5.1 Header Compression 



The header compression protocol is specific to the particular network layer, transport layer or upper layer protocol 
combinations e.g. TCP/IP and RTP/UDP/IP. The network layer protocol type, e.g. IP or PPP, is indicated during PDCP 
context activation as defined in [1]. The header compression protocols and their parameters are configured by upper 
layers for each PDCP entity. Compressor- and decompressor-initiated signalling between peer PDCP entities during 
operation is accomplished through in-band signalling. 

5.1 .1 Mapping of PID Values 

Depending on the configuration by upper layers (i.e. PDCP PDU type to be used and header compressor protocol), the 
PDCP sublayer shall be able to: 

• Identify different types of header compression protocols 

• IfRFC2507[4]: 

Distinguish different header compression protocol packet types within a header compression protocol 

• IfRFC3095[5]: 

Distinguish different contexts for a header compression protocol 

GMR-1 3G LLA Header Suppression protocol for spectrally efficient VoIP service is not mixed with other header 
compression protocols within a PDCP entity. 

The above requirements are realised by utilising the PID field in the PDCP PDU. 

The mapping of the PID values shall follow the general rules listed below: 

• PID values shall be mapped to the different packet types independently at each PDCP entity. 

• PID value "0" shall indicate "no compression." PID value "0" shall be used in a PDCP PDU containing in its 
Data field a PDCP SDU that is unchanged by the Sender and that shall not be decompressed by the Receiver. 

• PID values are mapped in ascending order, starting from 1, for every configured header compression protocol, 
in the order of configuration by the upper layer. The first available PID value is assigned to the first packet 
type of the header compression protocol as defined in the specification for this header compression protocol. 
PID values are mapped for all the specified packet types defined for the header compression protocol and in 
the order defined in clauses 5.1.2.2 and 5.1.3.3 for the respective header compression protocol. 

• PID values are re-mapped for the PDCP entity after any reconfiguration of the header compression protocols 
for that entity. 
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Table 1 illustrates an example of the PID value mapping to the packet types when five arbitrary header compression 
methods are configured for one PDCP entity: RFC 2507 [4], Methods A and B, RFC 3095 [5], and Method C. 
Method A, Method B, and Method C are imaginary header compression protocols introduced for the purpose of 
illustration. 

Table 1 : Example of the PID Value Mapping Table 



PID 
Value 


Optimisation Method 


Packet Type 





No header compression 


- 


1 


RFC 2507 [4] 


Full header 


2 


RFC 2507 [41 


Compressed TCP 


3 


RFC 2507 [4] 


Compressed TCP nondelta 


4 


RFC 2507 [4] 


Compressed non TCP 


5 


RFC 2507 [4] 


Context state 


6 


Method A 


Packet Type 1 of Method A 


7 


Method A 


Packet Type 2 of Method A 


8 


Method B 


Packet Type 1 of Method B 


9 


Method B 


Packet Type 2 of Method B 


10 


RFC 3095 [5] 


RFC 3095 [5] packet format 


11 


Method C 


Packet Type 1 of Method C 


12 


Method C 


Packet Type 2 of Method C 


13.. .31 


Unassigned value 


- 



5.1 .2 IP Header Compression (RFC 2507) 

The detailed operation of the RFC 2507 [4] header compression protocol shall be as specified in RFC 2507 [4]. The 
mechanisms related to error recovery and packet reordering are also described in RFC 2507 [4]. These mechanisms 
shall be included in the functionality of the header compression supported by PDCP. The implementation of the 
RFC 2507 [4] header compression functionality is not covered in the present specification and is left to the 
implementation. 



5.1.2.1 



Context Identifiers 



Context identifiers for RFC 2507 [4] shall only be included in the RFC 2507 [4] packet types format, as defined in 
RFC 2507 [4]. 



5.1.2.2 



Mapping of PID Values for RFC 2507 



FID values shall be mapped to the RFC 2507 [4] header compression packet types in the order presented in Table 2, 
where "n" is the number of PID values already mapped to other protocol packet types. 

Table 2: Mapping of PID Values for RFC 2507 [4] Header Compression Protocol 



PID value 


Optimisation Method 


Packet type 


n+1 


RFC 2507 [4] 


Full header 


n+2 


RFC 2507 [4] 


Compressed TCP 


n+3 


RFC 2507 [4] 


Compressed TCP non-delta 


n+4 


RFC 2507 [4] 


Compressed non-TCP 


n+5 


RFC 2507 [4] 


Context state 



5.1 .2.3 Management of Full Header Transmission 

Transmission of a full header packet may be controlled by the lower layer information. 

For a TCP stream, if the PDCP receives from lower layer the information of failed transmission of a single packet, the 
PDCP may send the next packet as a full header. 
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For a non-TCP stream, if the PDCP receives from lower layer the information of successful transmission of a full 
header packet, the PDCP may stop sending a full header packet that contains the same full header as the previously 
transmitted one. 

5.1 .3 Robust Header Compression (RFC 3095) 

The detailed operation of the, "Robust Header Compression (ROHC)" protocol shall be as specified in RFC 3095 [5]. 

5.1.3.1 Context Identifiers 

The context of the RFC 3095 protocol is defined in [5]. RFC 3095 [5] can be configured to support one or several 
contexts. Each context is identified by a value known as the context identifier (CID). 

5.1.3.2 Void 

5.1 .3.3 Mapping of PID Values for RFC 3095 

The following PID value shall be mapped to the RFC 3095 [5] header compression protocol as presented in Table 3, 
where n is the number of PID values already assigned to other protocol packet types. 

Table 3: Mapping of PID Values for RFC 3095 [5] Header Compression Protocol 



PID value 


Optimisation Method 


Pacl<et type 


n+1 


RFC 3095 [5] 


RFC 3095 [5] packet format 



5.1.3.4 Void 

5.1.3.5 Protocol Parameters 

RFC 3095 [5] has two types of parameters: 

• Configuration parameters: these are mandatory and shall be configured between compressor and decompressor 
peers. 

• Implementation parameters: these are optional and, when used, stipulate how RFC 3095 [5] operates. 
These parameters are categorized into four different groups, as defined below: 

• M: Mandatory and configured by upper layers. 

• MO: Parameters that shall be supported and when used can only be configured or triggered by upper layers. 

• O: Optional RFC 3095 [5] parameters that are not configured by upper layers. They may be used locally (i.e. 
Network and/or MES) for RFC 3095 [5]. 

• N/A: Parameters that are not used in RFC 3095 [5]. 

The usage and definition of the parameters shall be as specified below: 

• MAX_CID (M): This is the maximum CID value that can be used. One CID value shall always be reserved for 
uncompressed flows. 

• LARGE_CIDS: This is not configured by upper layers but inferred from the configured value of MAX_CID 
according to the following rule: 

If MAX_CID > 15, then LARGE_CIDS = TRUE else LARGE_CIDS = FALSE. 

• PROFILES (M): Profiles are used to define which profiles are allowed to be used by the MES in uplink. In 
downlink, all the profiles defined in [5] shall be supported. 

• FEEDBACK_FOR (N/A). 
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MRRU (M): Segmentation is not used by default. 

NO_OF_PACKET_SIZES_ALLOWED (N/A). 

PACKET_SIZES_ALLOWED (N/A). 

PAYLOAD_SIZES (O). 

NO_OF_PACKET_SIZES_USED (O). 

PACKET_SIZES_USED (O). 

CONTEXT_REINITIALIZATION (MO). 

MODE (O). 

CLOCK_RESOLUTION (O). 

REVERSE_DECOMPRESSION_DEPTH (M): Default value is that reverse decompression is not used. 

5.1 .3.6 Configuration by RRC 

If the variable "PDCP_ROHC_TARGET_MODE" (see TS 125 331 [2]) is stored in the MES, and if appHcable for the 
ROHC profile applied, the de-compressor shall only perform the operational state transitions defined in RFC 3095 [5] 
to the stored mode. 

If the variable "PDCP_ROHC_TARGET_MODE" (see TS 125 331 [2]) is not stored in the MES, the de-compressor 
shall not restrict the operational state transitions defined in RFC 3095 [5]. 

5.1 .4 GMR-1 3G LLA Header Suppression for Spectrally Efficient VoIP 

GMR-l 3G LLA Header suppression for spectrally efficient VoIP is fully specified in Annex A. 

5.1 .5 Data Compression 

Data compression is used to compress the payload of a non-encrypted IP datagram. ITU-T Recommendation V.44 [8] 
data compression procedure shall be used as the data compression algorithm. V.44 has two states of operations: stateful 
and stateless. The data compression is applied to the payload of the UDP/IP packet or TCP/IP packet. There are two 
data compression modes: 

• Stateful mode 

• Stateless mode 

The stateful mode is typically used to compress a packet that is transported on a reliable link, while stateless mode is 
typically used to compress a packet that is transported on unreliable link. 

For stateful compression mode, the decompression of the current packet will affect the decompression of the subsequent 
packets. Transmission error that may corrupt the dictionary of the current decompression will affect the decompression 
of the subsequent packets. Most TCP traffic is transported on L2 Acknowledged mode. Hence, since TCP packet is 
mostly free of transmission error, stateful compression mode is typically suitable for TCP packet. 

For stateless compression mode, transmission error will not affect the decompression of the subsequent packets since 
each packet is decompressed independently from the previous packets. Typically stateless compression mode is applied 
to UDP packet since most UDP traffic is transported in L2 Unacknowledged mode. 

RTP traffic is typically not compressed since usually RTP traffic, for example voice traffic, is already compressed. 

V.44 Data Compression is specified in Annex D. 
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5.2 



PDCP Setup 



5.2.1 PDCP Protocol Information from RNC to MES 

While establishing the radio bearer, the Radio Network Controller (RNC) sends RADIO BEARER SETUP message to 
the MES (see Figure 2). This message includes the PDCP Info IE that contains PDCP protocol info. 



MES 



RNC 



RADIO BEARER SETUP 



RADIO BEARER SETUP COMPLETE 



Figure 2: PDCP Info Exchange 

1) The RNC sends the RADIO BEARER SETUP message to the MES. The message contains the IE and PDCP 
Info, which includes information on the PDCP protocol. 

2) The MES replies with RADIO BEARER SETUP COMPLETE message. 

5.2.2 PDCP Capability Information from MES to RNC 

This indicates the algorithms and the value range of parameters supported by the MES PDCP. This information is sent to 
the RNC, either while setting up the RRC connection or while updating the MES capability information. 



MES/Compressor 



RNC/ Decompressor 



1. RRC CONNECTION REQUEST 



2. RRC CONNECTION SETUP 

3. RRC CONNECTION SETUP COMPLETE 



Figure 3: IVIES Capability Information 



RRC Connection Setup 



1) RNC initiates connection setup by sending RRC CONNECTION REQUEST message. 

2) While setting up RRC Connection, the RNC sends the RRC CONNECTION SETUP message to the MES. 
This message includes the Capability Update Requirement information element. 

3) If the Capability Requirement is set in the request message, the MES in its reply RRC CONNECTION SETUP 
COMPLETE message includes the MES RNC lu mode Radio Access Capability IE. This IE is structured and 
coded according to the specification used for the corresponding system type. The IE includes the PDCP 
capability IE that includes the header compression parameters. 
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5.2.3 PDCP Entity Creation/Deletion 



MES 
C 


RRC MES PDCP MESRLC RNC RLC RNC PDCP RNC 

RADIO BEARER SETUP I 


:rrc 

SAP, 
IS, 


;PDCP-CONFIG-( 


?eq 

SAP, 

IS. 


(PDCP Info, ...) 
RADIO BEARER SETUP COMPLb 1 b 






PDCP-lnfo, RLC- 

SN_Sync, R/l/C 

Context-Info) 








C 


;PDCP-CONFIG-l 


PDCP-lnfo, RLC- 

SN_Sync, R/l/C 

Context-Info) 



Figure 4: PDCP Entity Creation 



PDCP Entity Creation 



1) On the MES side, when the MES RRC receives a RADIO BEARER SETUP message, it shall use the primitive 
CPDCP-CONFIG-Req to configure the PDCP entity and the header compression protocols to be used. 

2) On the RNC side, when the RNC RRC receives the RADIO BEARER SETUP COMPLETE message, it shall 
use the primitive CPDCP-CONFIG-Req to configure the PDCP entity. 



MES RRC 

i 



MES PDCP MES RLC 



RNC RLC 



RNC PDCP 



RNC RRC 



C^DCP^RELEAS&Req 



RADIO BEARER RELEASE 



RADIO BEARER RELEASE COMPLETE 



^ 

Ct'DCP-RELEASE- 

< 



Req 



Figure 5: PDCP Entity Deletion 



PDCP Entity Deletion 



1) On the MES side, when the MES RRC receives a RADIO BEARER RELEASE message, it shall release all 
the resources associated with that radio bearer. The MES RRC sends CPDCP-RELEASE-Req message to the 
MES PDCP to release the PDCP entity. 

2) On the RNC side, when the RNC RRC receives the RADIO BEARER RELEASE COMPLETE message, it 
shall release all the resources associated with that radio bearer. The RNC RRC sends CPDCP-RELEASE-Req 
message to the RNC PDCP to release the PDCP entity. 



5.3 



Data Transfer 



If header compression is configured, the PDCP entity in the Sender shall: 

• Perform header compression upon reception of a PDCP SDU from upper layer. 

• Submit the PDCP PDU to lower layer in the sequence received from the upper layer. 
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When the PDCP entity at the Receiver receives the PDCP PDU from lower layers, it shall: 

• Perform header decompression (if header compression is configured) of the PDCP PDU to obtain the PDCP 
SDU. 

• Deliver the PDCP SDU to the upper layer in the order received from the lower layer. 

• If the received PDCP PDU is of type PDCP SeqNum: 

Follow the procedure in clause 5.6.1.2. 

5.3.1 Data transfer over Acknowledged Mode RLC 

Figure 6 shows the PDCP data transfer over acknowledged mode RLC. 
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Figure 6: PDCP Data Transfer Over Acknowledged Mode RLC 

NOTE: If the primitive RLC-AM-DATA.req is used with parameter CNF, the primitive RLC-AM-DATA.cnf is 
delivered. Otherwise, this primitive is not delivered. 

5.3.2 Data transfer over Unacknowledged and Transparent Mode RLC 

Figure 7 shows the PDCP data transfer over unacknowledged or transparent mode RLC. 
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Figure 7: PDCP Data Transfer Over Unacknowledged or Transparent Mode RLC 
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5.3.3 RoHC Data Flow 



MES/Compressor 



RNC/ Decompressor 



PDCP Entity 



1. Contains required 

parameters from upper 

layer 



PDCP Entity 



2. IR 
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4.ACK 



5. Type 0/ 1 

6. Type 0/1 
7. Incorrect Packet 



8. NACK 

9TypelR/ IR-DYN 



10. ACK 



Figure 8: RoHC Data Flow 

An example message flow is shown in Figure 8. This example shows the following steps: 

1) The PDCP entities on the compressor/decompressor side are created. They are passed appropriate parameters 
from the upper layer specifying the compression protocol to be used, lower layer protocol to be used, etc. 

2) Initially, the compressor sends IR packets containing full context information to the decompressor. 

3) The compressor moves to First Order (FO) state and starts sending IR-DYN packets containing the dynamic 
context information. 

4) After it receives feedback acknowledging the packets (R-mode and optionally in O-mode), the compressor 
transitions to the Second Order (SO) state. 

5) Once the decompressor receives the complete context information, it transitions to the Full Context (FC) state 
and start sending the compressed header packets Type 0/1 . 

6) The compressor then keeps sending the compressed header packets Type 0/1. The decompressor sends no 
feedback in case of correct Type 0/1 packets. 

7) However, if it receives a packet that fails the CRC check. 

8) It sends back a Negative Acknowledgement (NACK). 

9) Upon a configurable timer expiry or receiving an explicit request from the decompressor, the compressor 
sends IR/IR-DYN packets to refresh the decompressor context. 

10) The decompressor sends positive acknowledgement for such packets. 
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5.3.4 Compression/Decompression Flow in GMR-1 3G LLA Profile 
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Figure 9: GMR-1 3G LLA Header SuppressionProfile 

The two PDCP entities initially are configured by the upper layers with the header compression protocol to be used and 
the parameters for those protocols. The compressor sends N IR packets to the decompressor in RLC acknowledged 
mode to establish static context. This ensures reliable delivery of IR packets to the decompressor. Upon confirmation 
from L2 that all frames belonging to IR packets have been successfully delivered to the decompressor, the compressor 
informs the N AS regarding the successful creation of the PDCP contexts at the decompressor. For subsequent 
procedures, the compressor always sends an IR packet in RLC acknowledged mode to update or to create a new context 
at the decompressor. After this, the compressor proceeds with sending header free packets to the decompressor side. 



5.4 



SRNS Relocation 



In case of Satellite Radio Network Subsystem (SRNS) Relocation, the upper layer indicates to PDCP to perform either 
the re-initialisation or the context relocation of the compression protocols of an RB. In the present specification, context 
relocation is only applicable to GMR-1 3G LLA Header Suppression. 

5.4.1 Lossless SRNS Relocation 

Not supported in GMR-1 3G. 

5.4.2 Context Relocation for GMR-1 3G LLA Header Suppressed Session 

For the GMR-1 3G LLA Header Suppression, the snapshot of forward and return directions of the header compressor 
context and the frame number shall be transferred to the target RNC. The target RNC shall recreate header compressor 
context based on this information. The header compressor context is shown in Table 4. 
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Table 4: Header Compressor Context Relocation for GMR-1 3G LLA Header Suppression 



Context Type 


Field 


Bits 


Comment 


Static IPv4 


IP Version 


4 






ToS 


8 


Only if IP version = 4 




Source addr 


32 


Only if IP version = 4 




Dest addr 


32 


Only if IP version = 4 


Static IPv6 


IP Version 


4 






Traffic class 


8 


Only if IP version = 6 




Flow label 


20 


Only if IP version = 6 




Source addr 


128 


Only if IP version = 6 




Dest addr 


128 


Only if IP version = 6 


Static UDP 


Source port 


16 






Dest port 


16 




Static RIP 


RTP version 


2 






Payload type 


7 






SSRC 


32 




Dynamic 


IPv4 ID 


16 


Only if IP version = 4 




RTP sequence 


16 






RTP timestamp 


32 






Last frame number 


32 


Last frame number received in UL 



After handover has been completed, the PDCP at the new RNC shall generate the dynamic parts of the context 
according to the following procedures: 

• New IP Id = Old IP ID + (new FN - old FN) 

• New RTP Seq = Old RTP Sequence Number + 1 

• New RTP timestamp = Old RTP timestamp + (new FN - old FN) x 320 

• The above procedure shall account for FN rollover 

5.4.3 Context Relocation for All other Session Type 

Not supported in GMR-1 3G. 

5.5 Lossless DL RLC PDU Size Change 

Not supported in GMR-1 3G. 

5.6 General Procedures 

5.6.1 PDCP Sequence Numbering 

The value of the PDCP sequence number ranges from to 65535. The PDCP SN window size indicates the maximum 
number of PDCP SDUs, not confirmed to have been successfully transmitted to the peer entity by lower layer, that can 
be numbered at any given time. The PDCP SN window size is configured by upper layers. PDCP sequence numbers are 
set to "0" when the PDCP entity is set-up for the first time. 

In the following, the "submission/reception of a PDCP SDU to/from lower layer" is used as a synonym for the 
submission/reception of a PDCP Data PDU or a PDCP SeqNum PDU to/from lower layer that carries in its data field a 
compressed or uncompressed PDCP SDU. 

PDCP sequence numbers shall not be decremented in a PDCP entity. 

5.6.2 PDCP Sequence Number Synchronization 

Not supported in GMR-1 3G. 
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5.6.3 Sequence Number and Data Forwarding 

Not supported in GMR-1 3G. 

5.7 Header Compression and Decompression for IVIBIVIS 

Not supported in GMR-1 3G. 

5.7.1 Cell Change Inside the Same Cell Group 

Not supported in GMR-1 3G. 

5.7.2 Cell change between cell groups 

Not supported in GMR-1 3G. 

6 Services 

6.1 Services Provided to Upper Layers 

The following services are provided by PDCP to upper layers: 

• Transfer of user data. 

• Maintenance of PDCP SDU sequence numbers. 

6.2 Services Expected from RLC Layer 

For a detailed description of the following functions, see [3]: 

• Transparent data transfer Service. 

• Unacknowledged data transfer Service. 

• Acknowledged data transfer Service. 



7 Elements for Layer-to-Layer Communication 

The interaction between the PDCP layer and other layers are described in terms of primitives where the primitives 
represent the logical exchange of information and control between the PDCP layer and other layers. The primitives shall 
not specify or constrain implementations. 

7.1 Control Plane 

7.1 .1 Primitives between PDCP and Upper Layers 

The primitives between PDCP and upper layers are shown in Table 5. 
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Table 5: Primitives Between PDCP and Upper Layers 



Generic Name 


Parameter 


Req. 


Ind. 


Resp. 


Conf. 


CPDCP-CONFIG 


PDCP-lnfo, RLC-SAP SN Sync, 
R/I/C/RS, Context-Info 


Not Defined 


Not Defined 


Not Defined 


CPDCP-CONTEXT 


None 


Not Defined 


Not Defined 


Context- Info 


CPDCP-RELEASE 


RLC-SAP 


Not Defined 


Not Defined 


Not Defined 


CPDCP-SN 


PDCP SN 


Not Defined 


Not Defined 


Not Defined 



Each Primitive is defined as follows: 

1) CPDCP-CONFIG-Req. 

CPDCP-CONFIG-Req is used to configure and - in the case of already existing PDCP entity - to 
reconfigure a PDCP entity and to assign it to the radio bearer associated with that entity. 

2) CPDCP-RELEASE-Req. 

CPDCP-RELEASE-Req is used by the upper layers to release a PDCP entity. 

3) CPDCP-SN-Req. 

This primitive is used at the network side. CPDCP-SN-Req is used to transfer the PDCP SN to PDCP. 

4) CPDCP-CONTEXT-Req./Conf 

CPDCP-CONTEXT-Req initiates specific actions in the source RNC in order to perform context 
relocation as a part of the SRNS relocation. The primitive is applicable only in the source RNC. 

CPDCP-CONTEXT-Conf is used to transfer the header compression context information from PDCP to 
upper layer in order to perform context relocation as a part of the SRNS relocation. The primitive is 
applicable only in the source RNC. 

The following parameters are used in the primitives: 

1) PDCP-lnfo: 

Contains the parameters for each of the header compression protocols configured to be used by one 
PDCP entity. 

2) RLC-SAP: 

The RLC-SAP (TM/UM/AM) is used by the PDCP entity when communicating with RLC sublayer. 

3) SN_Sync: 

Indicates that PDCP should start the PDCP SN synchronization procedure. 

4) Next_Send_SN: 

The Send PDCP SN of the next PDCP SDU to be sent. There is one in the uplink (UL_Send PDCP SN) 
and one in the downhnk (DL_Send PDCP SN). Refer to clause 5.4. L 

5) Next_Receive_SN: 

The Receive PDCP SN of the next PDCP SDU expected to be received. There is one in the uplink 
(UL_Receive PDCP SN) and one in the downlink (DL_Receive PDCP SN). Refer to clause 5.4.1. 

6) PDCP SN: 

This includes a PDCP sequence number. 
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7) R/I/C/RS 



Indicates that PDCP should Re-initiaHze (R)/InitiaHze (I) the header compression protocols. 
Alternatively (Context-relocation, C), it indicates that the MES PDCP shall perform specific actions 
related to context relocation during SRNS relocation. (RS) indicates to Re-initialize while keeping the 
static part of the header compression (only for RFC 3095 [5]). The R/I/C/RS indication is given 
separately for each of the configured header compression protocols, if several exist for a given radio 
bearer. 



8) Context-Info: 



Contains the header compression context information of each of the header compression protocols that 
are subject to the context relocation during SRNS relocation. 



7.2 



User Plane 



7.2.1 Primitives Between PDPC and Upper Layer 

PDCP interacts with upper layer in the user plane at PDCP-SAP. 

Table 6: Primitives Between PDCP and Upper Layers in User Plane 



Generic Name 


Parameter 


Req. 


Ind. 


Resp. 


Conf. 


PDCP-DATA 


Data 


Data 


Not Defined 


Not Defined 



PDCP-DATA-Req./Ind. 

PDCP-DATA-Req is used by the upper user -plane protocol layers to request a transmission of an upper layer PDU. 
PDCP-DATA-Ind is used to deliver a PDCP SDU that has been received to upper user plane protocol layers. 

7.2.2 Primitives Between PDPC and RLC 

Table 7: Primitives Between RLC and Upper Layers 



Generic Name 


Parameters 


Req. 


Ind. 


Resp. 


Conf. 


RLC-AM-DATA 


Data, CNF, DiscardReq, MUl, 
IVIES- ID type indicator 


Data, Discardlnfo 


Not Defined 


Status, MUl 


RLC-UM-DATA 


Data, IVIES-ID type indicator, 
DiscardReq, MUl 


Data 


Not Defined 


MUl 


RLC-TM-DATA 


Data, MES-ID type indicator, 
DiscardReq, MUl 


Data, Errorjndicator 


Not Defined 


MUl 



Each Primitive is defined as follows: 
1) RLC-AM-DATA-Req/Ind/Conf 



RLC-AM-DATA-Req is used by the upper layers to request transmission of an RLC SDU in 
acknowledged mode. 

RLC-AM-DATA-Ind is used by the AM RLC entity to deliver to the upper layers an RLC SDU that has 
been transmitted in acknowledged mode and to indicate to the upper layers the discarded RLC SDU in 
the peer RLC AM entity. 

RLC-AM-DATA-Conf is used by the AM RLC entity to confirm to the upper layers the reception of an 
RLC SDU by the peer-RLC AM entity or to inform the upper layers of a discarded SDU. 
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2) RLC-UM-DATA-Req/Ind/Conf 

RLC-UM-DATA-Req is used by the upper layers to request transmission of an RLC SDU in 
unacknowledged mode. 

RLC-UM-DATA-Ind is used by the UM RLC entity to deliver to the upper layers an RLC SDU that has 
been transmitted in unacknowledged mode. 

RLC-UM-DATA-Conf is used by the UM RLC entity to inform the upper layers of a discarded SDU. 

3) RLC-TM-DATA-Req/Ind/Conf 

RLC-TM-DATA-Req is used by the upper layers to request transmission of an RLC SDU in transparent 
mode. 

RLC-TM-DATA-Ind is used by the TM RLC entity to deliver to the upper layers an RLC SDU that has 
been transmitted in transparent mode. 

RLC-TM-DATA-Conf is used by the TM RLC entity to inform the upper layers of a discarded SDU. 

Primitive Parameters 

The following parameters are used in the primitives: 

1) The parameter data is the RLC SDU that is mapped onto the data field in RLC PDUs. When AM or UM RLC 
entities are used, the length of the data parameter is a multiple of 8 bits; otherwise when the TM RLC entity is 
used the length of the data parameter is a bit-string whose length need not be a multiple of 8 bits. 

2) The parameter Confirmation Request (CNF) indicates whether the transmitting side of the AM RLC entity 
needs to confirm the reception of the RLC SDU by the peer-RLC AM entity. If required, once all AMD PDUs 
that make up the RLC SDU are positively acknowledged by the receiving AM RLC entity, the transmitting 
AM RLC entity notifies the upper layers. 

3) The parameter Message Unit Identifier (MUI) is an identity of the RLC SDU, which is used to indicate which 
RLC SDU that is confirmed with the RLC-AM-DATA-Conf. primitive, or discarded with the RLC- 
AM/UM/TM-DATA-Conf primitive. 

4) The parameter Discardlnfo indicates to the upper layer the discarded RLC SDU in the peer-RLC AM entity. It 
is applicable only when in-sequence delivery is configured and it is to be used when the upper layers require 
the reliable data transfer. 

5) The Error_Indicator parameter indicates that the RLC SDU is erroneous. Erroneous SDU will be discarded 
(see Table 7 and its explanation). 

6) The parameter MES-ID type indicator indicates the RNTI type (U-RNTI or C-RNTI) to be used for the 
associated RLC SDU. This parameter is not required at the MES. 

7) The parameter DiscardReq indicates whether the transmitting RLC entity needs to inform the upper layers of 
the discarded RLC SDU. If required, the transmitting RLC entity notifies the upper layers when the SDU is 
discarded. 

8) The parameter Status is only applicable for AM operation. This parameter indicates whether a RLC SDU is 
successfully transmitted or discarded. 



8 Elements for Peer-to-Peer Communication 

8.1 Protocol Data Units 

Different PDU formats are defined for the PDCP protocol: one not introducing any overhead to the (compressed) PDCP 
SDU, others introducing such overhead. 



£75/ 



GMR-1 3G 25.323 28 ETSI TS 101 376-4-15 V3.3.1 (2012-12) 

8.2 Formats 

A PDCP PDU shall be a multiple of 8 bits if the RLC entity is configured for unacknowledged or acknowledged mode. 
Otherwise, if the RLC entity is configured for transparent mode, it is bit-aligned. In Tables 8, 9 and 10, bit strings are 
represented as follows: the first bit is the leftmost one on the first line of the table, the last bit is the rightmost on the last 
line of the table, and more generally, the bit string is to be read from left to right and then in the reading order of the 
lines. 

SDUs are bit strings with any non-null length. If not compressed within PDCP an SDU is included from the first bit 
onward. 

8.2.1 PDCP-No-Header PDU 

The PDCP-No-Header PDU does not introduce any overhead to the PDCP SDU. The use of the PDCP-No-Header PDU 
is configured by the upper layer. 

The format of the PDCP-No-Header PDU is shown in Table 8. 

Table 8: PDCP-No-Header PDU 



Data 



8.2.2 PDCP Data PDU 

The PDCP Data PDU is used to convey: 

• Data containing an uncompressed PDCP SDU; or 

• Header compression related control signalling; or 

• Data that has been obtained from PDCP SDU after header compression. 
The format of the PDCP Data PDU is shown in Table 9. 

Table 9: PDCP Data PDU Format 



PDU type 



RID 



Data 



8.2.3 PDCP SeqNum PDU 

The PDCP SeqNum PDU is used to convey a PDCP SDU sequence number and: 

• Data containing an uncompressed PDCP SDU; or 

• Data that has been obtained from PDCP SDU after header compression. 
The format of the PDCP SeqNum PDU is shown in Table 10. 
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Table 10: PDCP SeqNum PDU Format 



PDU type 



PID 



Sequence number 



Data 



8.3 



Parameters 



If not otherwise mentioned in the definition of each field, then the bits in the parameters shall be interpreted as follows: 
the left most bit in the first row is the most significant bit; and the right most bit is the last row is the least significant 
bit. 

Unless otherwise mentioned, integers are encoded in standard binary encoding for unsigned integers. In all cases, the 
bits appear ordered from MSB to LSB when read in the PDU. 

8.3.1 PDU Type 

Length: 3 bits. 

The PDU Type field indicates the type of PDCP data PDU. The PID field identifies the exact header compression 
packet type and the setting of the PID values is described in clause 5.1.1. 

Table 11 : PDU Type Field Bit 



BitO 


PDU Type 





Payload Data is uncompressed 


1 


Payload Data is compressed 



Table 12: PDU Type Field Bit 1 and 2 



Bit 1 and 2 


PDU Type 


00 


PDCP Data PDU 


01 


PDCP SeqNum PDU 


10 
to 

11 


Reserved (PDUs witli this encoding are invalid for tliis version of tlie 
protocol) 



If the number of CIDs is greater than the number that can be accommodated in the PID field (referred to as CID field in 
the table) of the PDCP PDU header, then the CID of 1 or 2 octets in the ROHC packet is used. The PID field is 
therefore unused in this case. 

Bit of the PDU Type indicates the data compression mode. If this bit is 0, the data decompressor should reset the 
dictionary. 

8.3.2 PID 

Length: 5 bits. 

The PID field indicates the used header compression and packet type or a context identifier. 

Table 13: PID Field 



Bit 


Description 


00000 


No header compression 


00001 
to 

11111 


Dynamically negotiated header compression identifier, as described 
in clause 5.1.1 
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The PID field value indicates the used header compression protocol type and packet type, or CID. A specific header 
compression protocol may utilize a certain range of consecutive values from the PID field value space for different 
packet types. The Receiving PDCP entity should perform the necessary operation (e.g. header decompression) 
according to the PID field value. 

8.3.3 Data 

The Data field may include any one of the following: 

• Uncompressed PDCP SDU 

• Header compressed PDCP SDU 

• Header compression protocol feedback information 

8.3.4 Sequence number 

Length: 16 bits 

PDCP SDU sequence number. 

9 Handling of Unknown, Unforeseen, and Erroneous 

Protocol Data 

9.1 Invalid PDU Type 

If a PDCP entity receives a PDCP PDU with a PDU Type set to Reserved (see clause 8.3.1), it shall: 

• Discard the PDCP PDU 

If a PDCP entity is not configured for lossless SRNS Relocation or lossless DL RLC PDU size change and it receives a 
PDCP SeqNum PDU, it shall: 

• Discard the PDCP SeqNum PDU 

9.2 Invalid PID value 

If a PDCP entity receives a PDCP PDU with a PID value that is not mapped with a valid packet type (see clause 5.1.1), 
it shall: 

• Discard the PDCP PDU 
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Annex A (normative): 

GMR-1 3G LLA Header Suppression 

A.1 Introduction 

A GMR-1 3G-enabled RNC shall only be deployed in All-IP UMTS networks. 

GMR-1 3G introduces VoIP speech services by interfacing with a packet domain UMTS core network using the 3GPP 
standard lu-PS interface (see TS 125 410 [i.l]). Real time protocol (RTP) (see RFC 3550 [i.2]) is used to carry encoded 
speech data for VoIP services. 

In order to ensure that the smallest hand-held terminals can close the link margin for the voice service, the service will 
be provided on PNB(1,6) or PNB(1,3) uplink channels. The downlink channels can be shared. GMR-1 3G spectrally- 
efficient VoIP service uses either a 2,45 or 4 kbps codec. 

The satellite link is a resource-limited system in which any additional header information can significantly affect the 
total capacity. The RFC 3095 [5] RoHC scheme that reduces RTP/UDP/IP header size to 1 to 4 octets is not sufficient 
and hence a header compression scheme is defined in the present document where no protocol header is transmitted 
over the GMR-1 3G satellite radio interface by completely suppressing the IP/UDP/RTP headers. This header 
suppression scheme requires GMR-1 3G lower layer assistance. The GMR-1 3G LLA Header Suppression scheme is 
supported in both uplink and downlink directions. 

A.1 .1 GiVIR-l 3G LLA Header SuppressionService Options 

The GMR-1 3G LLA Header Suppression service transports IP/UDP/RTP for SE-VoIP service that is optimised for the 
GMR-1 3G radio interface. 

The GMR-1 3G LLA Header Suppression that is supported on the satellite radio interface is an optimized version of the 
ROHC LLA profile. It is adapted for use on the GMR-1 3G Satellite Radio Interface as follows: 

• Not all the packet types mentioned in ROHC LLA are used in the GMR-1 3G LLA. 

• In the ROHC LLA, both static and dynamic contexts are established by exchanging packets between 
compressor and decompressor over the air. In the GMR-1 3G LLA, the radio interface packet exchange is 
required only to create the static context. The creation of dynamic context information is localized at the 
receiving side as described in the subsequent clauses of this annex. 



A.2 Silence Suppression 



The GMR-1 3G LLA Header Suppression is supported for voice codecs is operating either at 2,45 kbps or 4 kbps. The 
following paragraphs describe characteristics of the codec, including its silence packets and comfort noise generation 
concepts. 

During a normal conversation, the participants typically alternate their speech, such that on average each direction of 
transmission is occupied about 50 % of the time. Discontinuous Transmission (DTX) is a mode of operation where the 
transmitters are switched on only for those frames that contain useful information. This is done for the following three 
purposes: 

• In the MES, battery life will be prolonged, or a smaller battery could be used for a given operational duration. 

• The average transmit power level over the radio interface is reduced, leading to better Radio Frequency (RF) 
spectrum efficiency. 

• Satellite power utilization on the forward link is optimized. 

However, to support the working of the GMR-1 3G LLA header suppression scheme, the DTX feature related to silence 
packets and comfort noise has been moved from the codec to the GMR-1 3G link layer. 
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The voice codec that is supported by GMR-1 3G LLA header suppression generates frames every 20 ms, each of which 
could be a silence pattern or a voice frame: 

• On the network side, the Media gateway sends 20 ms voice packets to the RNC. 

• On the MES side, during any active voice period, the codec generates voice frames. The packetization module 
creates an RTP packet for each 20 ms voice frame. 

• If the upper layer sends the VoIP packet in 20 ms frame size, the lower layer at the RNC and at the MES will 
combine two 20 ms packets before transmitting it over the air. 

• If the upper layer sends the VoIP packet in 40 ms frame size, the lower layer at the RNC and at the MES will 
not need to combine the packets, it just transmits it over the air. 

• During an inactive voice period (silence period), a silence frame is generated every 20 ms. The packetization 
module creates an RTP packet for each 20 ms silence frame. The payload of a silence frame packet will always 
have a unique pattern: this is the silence descriptor (SID) that distinguishes silence frame packets from real 
voice packets. These silence frame packets have the same payload length as real voice packets. 

• The silence frame and voice packets belong to the same RTP stream, and thus, maintain continuity of RTP 
sequence numbers. 

• If the decoder does not receive any packets during its sampling period, it either generates comfort noise or 
error concealment packets. Error concealment packets are generated if the last received packet is a voice 
packet, while comfort noise is generated if the last received packet is a silence packet. The information on the 
last silence packet is used to generate subsequent silence packets in 20 ms interval when no packets are 
received. If decoder does not receive frames or receives frames with errors during its consecutive N sampling 
periods, the decoder controlling application mutes the decoder. 



A.3 GMR-1 3G LLA Header Suppression Overview 

In order to completely eliminate the compressed header in GMR-1 3G, all the functionality normally provided by the 
1 -octet header in the RFC 3095 [5] scheme has to be provided by other means, typically by utilizing functionality 
provided by the lower layers. The entity that implements the interface between GMR-1 3G LLA profile and the lower 
layer is called the assisting layer (AL). The GMR-1 3G LLA profile that performs header compression is termed the 
HCU application (HC, Upper Layer). The assisting layer is realized by the HCL application (HC, Lower Layer), which 
adapts between the GMR-1 3G LLA implementation and the physical layer. This assistant layer is assumed to have 
knowledge of the physical layer synchronization. 

A.3.1 Context and Functional Blocks 

Figure A.l shows the functional blocks involved in GMR-1 3G LLA Header Suppression at both the transmit and 
receive sides. For the purpose of the present document, the terms "transmitting side" and "receiving side" are used in 
relation to the type of interaction with the link layer. 
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Tx Side 



UPPER LAYER 



PDCP 



HCU 



HCU-HCLInterface 



HCL 



RLC/MAC 



Channel 



Rx Side 



UPPER LAYER 



PDCP 



HCU 



HCU-HCLInterface 



HCL 



RLC/MAC 



Figure A.I : GMR-1 3G LLA Functional Blocits 

In GMR-1 3G, the HCU application resides in the PDCP layer and performs header compression and decompression. 
The HCL application resides in the RLC/MAC layer and provides link layer assistant functions. 

Specifically, the transmitting side refers to the HCU-HCL pair for which the HCL application is supplying data to the 
link layer. Similarly, the receiving side refers to the HCU-HCL pair for which the HCL application is receiving data 
from the link layer. 

GMR-1 3G LLA Header Suppression will be used only for the SE-VoIP flow. The PHY layer transmission bursts for a 
spectrally-efficient VoIP flow are allocated the same number of slots on each TDMA frame. 

Packets will not have any header, nor any context identifier, and can only be sent from the compressor to decompressor. 

On the uplink, due to the use of a dedicated channel, it is possible to achieve RLC transparent mode data transmission, 
i.e. it is not required to send any RLC/MAC headers. On the downlink, shared channels are used, so a RLC/MAC 
header should be present. However, on a Ix downlink channel, a dedicated channel is provided where a RLC/MAC 
header will not be present. 

On a spectrally-efficient voice bearer channel, the burst may carry the following types of payloads: 

• Real voice 

• Silence frame 

The real voice and silence frame packets are distinguished from each other by the silence identifier field. The silence 
frame payload always has a unique pattern known as SID (or the silence identifier). 

The RRC entity for the spectrally-efficient VoIP service RAB will create one PDCP entity and two radio bearer IDs for 
the RLC/MAC, that is, one in transparent mode and the other in ACK mode. The context initialization packet (described 
later) will be sent via the ACK mode RLC instance, and header stripped packets will be sent via the RLC transparent 
mode. 

A.3.2 HCU Application Overview 

The HCU application is the process above the HCL application that generates and consumes data blocks. The HCU 
application refers to the header compression algorithm. 

To achieve GMR-1 3G LLA Header Suppression, the header decompressor residing in the HCU application at the 
receiving side is required to regenerate some of the information needed to decompress the IP/UDP/RTP headers of 
header-free packets as follows: 

• The HCU only obtains the Payload from the HCL. 
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• The HCU then regenerates the following information: 
Packet type (voice or silence frame). 
Vocoder Rate (2,45 kbps or 4 kbps). 
RTP timestamp. 
The HCU uses the following important functions supported by the HCL application: 



• 



In-order delivery of data frames over the radio interface every 40 ms (hence no extra header is used for in- 
order delivery). 

• Detection of packet losses over the radio interface. 

• TDMA frame number. 

• Recognition of voice or silence frame. 

A.3.3 HCL Application Overview 

To achieve GMR-1 3G LLA Header Suppression, the HCL application on the transmitting side: 

• Sends voice packets or silence frame packets (with no headers). 

• For silence frame packets, the first one is sent and then the HCL drops consecutive silence frame packets for 
the next one second. If there are many consecutive silence frame packets, one packet is sent over the air every 
second, thereby providing DTX operation. 

The HCL application on the receiving side: 

• Provides a loss indication to the associated connected service when a packet is damaged (e.g. when the 
physical frame is received with insufficient physical layer frame quality or is lost). The physical layer has a 
mechanism to detect a packet loss on a dedicated channel. 

A.4 GMR-1 3G LLA Header Suppression End-to-End 
Flow 

A.4.1 GMR-1 3G LLA Header Suppression Flow for Downlink 

This clause describes the end-to-end flow for the GMR-1 3G LLA Header Suppression between the RNC and MES. On 
the downlink, either a DCH or a PDCH channel will be used for the SB- VoIP service. A DCH channel is only used if 
the channel is Ix. 

A.4. 1.1 Transmitting Side 

The PDCP receives 40 ms or 20 ms RTP packets from the Core Network. These are handled as described below: 

• The transmitter side in the PDCP creates a compression context for the downlink based on the packet 
initialization sent by the PDCP at the MES side. The compression context creation procedures are explained in 
clause A.4.2. 

• The HCU on the transmitting side does not need to initialize the PDCP context at the peer HCU on the 
receiving side (at the MES). RTP packets received from the core network contain a 1 byte extension header 
between the normal RTP header and the payload. This extension header comprises 4 bits for frame type, 4 bits 
reserved, see Figures A. 2 and A. 3, and Table A. 1. 
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The PDCP shall compute the IP header checksum for IPv4 packets and UDP checksum for IPv6 packets. If 
there is a checksum verification error, the PDCP shall drop the packet. The PDCP should maintain statistics 
about how many RTP packets have been dropped. 

The PDCP shall classify RTP packets as voice, DTMF/Tone, or SID (Silence Insertion Descriptor) based on 
the well-known bit patterns of the payload. 

The transmitter side HCU application in the PDCP shall strip the RTP/UDP/IP header and the 1 byte extra 
header, and shall send the 40 ms or 20 ms payload to the RLC/MAC on the transparent mode interface. Along 
with the payload, the PDCP shall also send the timestamp from the RTP header, the classification (voice or 
SID), and the frame type information to the RLC/MAC. 

The HCL in the RLC/MAC shall send the packet to the PHY every 40 ms including an indication of the type 
of the packet (i.e. real voice, SID, DTMF/Tone, or frame erase). Note that if the packets come from the 
network every 20 ms, the RLC/MAC shall combine two 20 ms packets before sending it to the physical layer. 

The transmitter side HCL in the RLC/MAC provides the DTX operation, which means that it shall suppress 
silence frame packets in such a way that one such packet goes out to the physical layer once a second if there 
is a long silence period. 

If there is no packet required, the RLC/MAC schedules no header voice packet to be sent on the appropriate 
TBF and informs the physical layer. 

On dedicated channels, no RLC/MAC header is added. On a shared channel, although the same slot position, 
is used on every frame for a specific MES; a few bits of RLC/MAC header is added. 

When a packet is dropped by the PDCP or the HCL suppresses a silence frame packet, the RLC/MAC 
scheduler should schedule a packet from a best effort service (if available) on the slot where a voice or silence 
frame packet for this MES should have been sent. If there is no packet to fill the slot, the PHY layer should 
send a power control packet. 

The PHY classifies spectrally-efficient VoIP bursts from other bursts by using different unique words (UW). 
Note that IR packets and normal VoIP packets are sent on the same MAC slots. 



IPv4/IPv6 Hdr 
(20/40 bytes) 



UDP Hdr 
(8 Bytes) 



RTP Hdr 
(20 Bytes) 



Ext Hdr 
(1 Byte) 



Payload 



Figure A.2: Position of Extension l-leader 



Frame Type 
(4 bits) 



Reserved 
(4 bits) 



Figure A.3: Extension l-leader Contents 
Table A.I : Extension Header Coding 



Frame Type 


Vocoder Rate 





4,0 kbps 


1 


2,45 kbps 


2-15 


Reserved 
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A.4.1.2 Receiving Side 



The receiving side for the downlink flow receives a headerless packet every 40 ms TDMA frame. These are handled as 
described below: 

• PHY receives bursts on the downlink on timeslots allocated for the SE-VoIP service. On the downlink, the 
channel could be PDCH or DCH. 

• PHY interprets whether a burst contains a suppressed SE-VoIP packet or other packet (including the IR packet 
and KAB3) by the value of the UW (Unique Word). 

• PHY sends good packets to the RLC/MAC along with the TDMA frame number on which the packet was 
received, the burst classification information and the vocoder rate. 

• Based on the burst classification information, the RLC/MAC decides whether it should send the SDU to the 
PDCP entity either through the ACK mode RLC instance or Transparent mode RLC instance. Any IR packets 
shall be sent to the ACK mode RLC instance. The RLC/MAC shall ignore any KAB3 bursts received from the 
PHY layer. 

• The receiving side HCL in the RLC/MAC shall not split one RTP packet it receives every 40 ms into two data 
blocks. It passes the whole packet to the HCU layer. 

• The HCU layer in the PDCP, upon receiving headerless packet from HCL, shall regenerate the IP/UDP/RTP 
header for the packet from the context information and send it to the upper layer. 

• The HCU layer only has the static context. The dynamic context is handled as described below. The dynamic 
context contains the following information: 

RTP Sequence number 

IP Identification (in IPv4 packet headers) 

RTP Timestamp 

CRC 

Traffic Class (in IPv6 packet headers) 

Time-to-live (in IPv4 and Ipv6packet headers) 

DF, RND, and NBO flags (in IPv4 packet headers) 

Generic extension header list (in IPv4 and Ipv6 packet headers) 

• The receiving side shall assume random number X as the start value for the RTP sequence number and random 
number Z as the start value for the RTP timestamp when the context is established. Thereafter, the HCU layer 
shall use the frame number to generate the subsequent RTP sequence numbers and timestamp every 40 ms. 

The RTP timestamp shall be increased according to the size of the voice packetization. For example for 
packetization of 40 ms voice, sampled at 8 000 Hz, the RTP timestamp shall increase by 320 for each 
elapsed TDMA frame. 

• For IP Identification, another random number Y is assumed as the IP ID when the context is established. Every 
time the sequence number is incremented, the IP ID is also incremented by the same amount. The traffic class, 
time-to-live, and the flags are regenerated locally at the receiving side. The extension headers are not present 
in VoIP packets so they do not need to be handled. 

• The HCU in the PDCP sends the resulting 40 ms RTP packets (complete with regenerated headers) to the 
upper layer. 

• If the vocoder does not receive the next packet after playing a voice packet, it shall play error concealment 
packets. If the vocoder does not receive the next packet after playing a SID packet, it shall play the same SID 
packet until receives the next packet. 
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A.4.2 GMR-1 3G LLA Header Suppression Flow for Uplink 
A.4.2.1 Transmitting Side 

The PDCP receives RTP packets from the upper layer (from vocoder) every 20 ms along with the vocoder rate 
information. These are handled as described below: 

• The RTP payload types for the 4,0 kbps and the 2,45 kbps vocoder shall be unique. 

• RTP packets received from the upper layer shall contain a 1 byte extension header between the normal 
RTP header and the payload comprising, 4 bits for frame type, 4 bits reserved, (see Figures A.2 and A. 3, and 
Table A. 1). 

• The HCU in the PDCP classifies packets as either voice or silence (SID), based on the unique pattern of the 
payload. DTMF/Tone packets shall be treated as voice packets. 

• The HCU shall suppress the headers of all packets, including the 1 byte extension header, and send each 20 ms 
packet to the HCL along with the following information: 

RTP timestamp 

Vocoder rate 

Payload type: voice, DTMF/tone, SID 

• The HCL shall combine two 20 ms packets into one 40 ms packet and shall send each 40 ms packet along with 
the classification and vocoder rate information to the PHY. If the two 20 ms packets combined into one 40 ms 
packet are of different types (i.e. voice and SID), the HCL shall indicate to the PHY the type as that of the first 
20 ms packet. 

• When HCL encounters the first SID packet after a sequence or one or more voice packets, it shall transmit the 
complete SID packet. When there are many consecutive SID packets, the HCL sends to the PHY only 

one 40 ms SID packet every one second. Thus the HCL provides the DTX functions. 

NOTE: The PHY will send a power control frame if there is no other packet to send. 

A.4.2.2 Receiving Side 

The receiving side for the uplink, receives a headerless packet every TDMA frame. 

• Every 40 ms TDMA frame the PHY detects the burst received on the DCH channels or PDCH channels. Two 
cases are possible: 

PHY detects a good packet 

PHY detects CRC error 

• The PHY sends the good packets to the RLC/MAC. The PHY also provides vocoder rate information to the 
RLC/MAC. 

• The RLC/MAC shall then send the packet to the appropriate PDCP entity along vocoder rate. 

• The PDCP regenerates the IP/UDP/RTP header and adds this to the packet received from the RLC/MAC. 

• The receiving side shall assume random number X as the start value for the RTP sequence number and random 
number Z as the start value for the RTP timestamp when the context is established. Thereafter, the HCU layer 
shall use the frame number to generate the subsequent RTP sequence numbers and timestamp every 40 ms. 

The RTP timestamp shall be increased according to the size of the voice packetization. For example for 
packetization of 40 ms voice, sampled at 8000 Hz, the RTP timestamp shall increase by 320 for each 
elapsed TDMA frame. 

• The HCU in the PDCP sends 40 ms RTP packets towards the core network. 



£75/ 



GMR-1 3G 25.323 



38 



ETSI TS 101 376-4-15 V3.3.1 (2012-12) 



• If the vocoder does not receive packets after playing a voice packet, it shall play error concealment packets. If 
there is no packet in 60 ms or more, the voice decoder shall mute. If the vocoder does not receive packets after 
playing a SID packet, it shall play the same SID packet until it receives the next packet. 

A.4.2.3 PDCP Context Creation 

When the PDCP at RNC receives an uplink initialization packet to create the decompression context for the uplink, the 
PDCP at the RNC shall also use this initialization packet to create the compressor context for the downlink. The PDCP 
shall use the uplink destination IP address packet as its source IP address and the uplink source IP address packet as its 
destination IP address, see Figure A.4. 

The RTP payload type shall uniquely identify either a 4,0 kbps or 2,45 kbps vocoder. 

Similarly for the UDP port, the PDCP shall use the uplink destination UDP port packet as its source UDP port and the 
uplink source UDP port packet as its destination port. All other static headers in the RTP/UDP/IP headers shall be 
created by the PDCP. If the PDCP at the RNC side receives a RTP packet from the Core Network that cannot be 
associated with the existing compression context, the PDCP shall drop this RTP packet. 

At the MES side, after a SIP PRACK message is received, the SIP application layer shall convey information from the 
SDP content to the PDCP to be used to create the PDCP context. The PDCP context shall be sent also to the RNC 
immediately. Hence the probability of conflict between sending PDCP initialization to the RNC and sending SIP 180 
Ringing can be minimized (see RFC 3261 [11]). 



UPLINK VoIP Packet 



Rest of the IP Header 



IP Source Address 



IP Destination Address 



UDP Source Port 




Rest of UDP Header 



RTP Header 



Voice Payload 



To UT Upper Layer 
(Voice Decoder) 



PDCP Source IP Address 



PDCP Destination IP Address 
PDCP UDP Source Port 



PDCP UDP Destination Port 

PDCP Decompressor 
Context 



PDCP Compressor 
Context 



To the PDCP 
from the UT 
Upper Layer 



Figure A.4: PDCP Context Creation 

The PDCP layer shall also send this context as an IR packet to the RNC to allow the RNC to create the decompressor 
context for the uplink traffic. The RNC shall use this information to create the static parts of the header decompression 
context. The RNC shall also use the IR packet to create context for the downUnk direction by switching the IP/port 
source with IP/port destination as done in the MES. 
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Annex B (normative): 
ROHC Performance Testing 

B.1 Introduction 

This annex defines performance test cases for ROHC. 

The ROHC profile within scope is profile 0x0001 for compression of RTP/UDP/IP headers only. This annex is not 
meant to bring incoherent limitations to implementations, and is not meant to create a sub-specification of RFC 3095 [5] 
either, as a consequence of the requirements on performance that it defines. Note that this test is based on 20 ms frame 
size with 8kHz sampling rate, hence the timestamp increase by multiple of 160. For 40 ms frame size, the timestamp 
calculations shown in this clause should be multipled by a factor of two, i.e. the timestamp shall increase by multiple 
of 320. 

B.1 .1 Purpose of the Performance Testing 

The purpose of the test cases is to ensure that ROHC implementations meets minimal requirements that can fairly be 
expected when subjected to an input sequence that includes frequently occurring and commonly observed changes in 
the values of header fields. The metrics used correspond to: 

• The average compressed header size for an entire test sequence to assess an implementation's efficiency in 
terms of its overall compression ratio. 

• The average compressed header size for different sub-sequences within each test case to assess an 
implementation's ability to minimize the variance in compressed header size with respect to the selection of the 
packet format used for individual packets. 

The latter is to avoid a less desirable behaviour where a compressor would consistently and exclusively use two types of 
compressed header formats; one format that offers no compression but that completely updates and/or repairs the 
context, e.g. when the patterns of the header fields to be compressed do not allow optimal compression, and another 
format that provides the most efficient compression ratio otherwise. While it is noted that the use of larger headers is 
perfectly acceptable protocol-wise [5], the tests herein are meant to encourage compressor implementations to actively 
and efficiently implement compression. 

These metrics are defined so that they are not impacted by an implementation's specific robustness algorithm(s) as well 
as to allow a wide range of compression strategies. 

Compressor implementations are expected to implement robustness algorithms according to the optimistic approach for 
the U/O-modes of operation. The optimistic approach is the part of the selection of the packet format where a format 
that contains the necessary information to update a field is used a number N times, starting from the packet for which a 
new value has to be established in the decompressor context. While N is an implementation parameter, the metrics for 
each sequence in U/O-mode is expressed in terms of this parameter. Implementation should use the value N as an input 
parameter for the testing, to adapt to the expected robustness level required for the testing. The value of the parameter N 
is defined in each test case definition separately (the informative value is given in clause C.2.3). Similarly, R-mode 
operation requires that an update be conveyed to the decompressor until it gets acknowledged; however for R-mode, the 
relevant test cases provide explicit feedback messages when necessary. 

The performance tests for ROHC as described in this clause are carried out by providing a sequence of uncompressed 
IP/UDP/RTP packets to the ROHC RTP compressor, together with artificially generated feedback messages that are 
synchronized with the packet sequence. All packets in these sequences are built on the same base structure, with most 
field values being constant. The performance test cases define different change patterns for three specific fields: the 
IPv4 IP ID, the RTP SN, and the RTP TS. 
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B.1 .2 Input Sequence for Uncompressed Headers 

The structure of the IPv4/UDP/RTP header and IPv6/UDP/RTP header is outhned in clause B.3, along with tables of 
the values to be used for each field. Fields with values marked ANY can have any value; these are the addressing fields 
that uniquely identify the flow of packets being compressed and their respective value does not otherwise affect the 
expected compression ratio as they are either sent in uncompressed form or completely omitted in compressed packets. 
The checksum values are dependent on the entire content of the packet and are calculated according to their respective 
protocol specifications, RFC 768 [9] and RFC 791 [10], which are referred to in the tables. For the input sequence, the 
UDP checksum with IPv4 shall always be enabled and thus have a non-zero value, i.e. the two octets of the UDP 
checksum are always included as part of the calculation of the compressed header size for both IPv4 and IPv6. Each test 
sequence defines specific values to create varying change patterns for the IPv4 IP ID, the RTP SN, and the RTP TS. A 
dummy payload of an arbitrary non-zero value shall be appended at the end of the header data, following the RTP 
header. 

The outline of each test case follows the same format with respect to the input sequences and the requirements. Test la 
and lb are base tests using a well-behaving flow of packets as one of the inputs. All subsequent tests are based on test 
la or test lb, each with specific test events added to the packet flow of the base tests. 

B.1 .3 Feedback Format for the Test Cases 

The feedback messages used in the test cases, when applicable, are artificially generated and synchronized with the 
input sequence of uncompressed packets. Feedback messages are generated according to the following format: 

01234567 

+ + + + + + + + + 

I 1 1 1 1 I Code I feedback type octet 
+ + + + + + + + + 

lAcktypel Mode | SN | 
+ + + + + + + + + 

I SN I 

+ + + + + + + + + 

|0 l|0 l| 
+ + + + + + + + + 

I CRC I 

+ + + + + + + + + 

Where: 

Code is set to 0x4 (indicates that feedback data above the type octet is 4 octets) 

Acktype is set to 0x0 (means ACK) 

Mode is set as defined by the test case 

SN is set as defined by the test case 

CRC is the 8-bit CRC computed over the entire feedback payload including any CID fields but excluding the 
packet type, the 'Size' field and the 'Code' octet, using the polynomial defined in RFC 3095 [5]. 

NOTE: If the compressor uses the CID field in the compressed packet, the CID field should be included in the 
feedback packet and the Code and CID should be set as defined in [5]. 

B.1 .4 Feedback Generation for Test Cases (R-Mode Only) 

This clause defines a mechanism by which the test equipment shall dynamically generate feedback messages for each 
test case, once a transition to R-mode has been initiated and for the entire R-mode operation thereafter. Test cases may 
define additional feedback messages as input to the compressor. 
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The test equipment shall generate a feedback message when the ROHC packet type octet of the received compressed 
header matches any of the values as described in Table B.l. The compressed header type can be identified by inspecting 
the packet type octet of the compressed header, i.e. the first octet of the ROHC base header as defined in RFC 3095 [5]. 

Table B.1 : Bitmasks for Feedback Generation 



Compressed Header Type 

(binary mask) 

(Note) 


Outcome 


01XXXXXX 


Send feedback 


1 1 0xxxxx 


Send feedback 


1111110X 


Send feedback 


Other values 


No feedback 


NOTE: The symbol 'x' means 'any value'. 



The feedback message shall be of the format as described in clause B.1.3 using: 

• Mode is set to 0x3 (means R-mode) 

• SN is set to the RTP SN corresponding to the received compressed header 

The test equipment shall index the input sequence of uncompressed headers using the RTP Sequence Number, and it 
shall associate the correct RTP SN to each compressed header that it receives back from the compressor. The test 
equipment can derive the RTP SN by counting the number of received compressed headers. 

NOTE: The purpose of this mechanism is only to provide feedback to the compressor when operating in R-mode; 
it is not meant to make further verifications of any specific ROHC functionality and applies only to the 
test cases defined in this annex. 

B.1 .5 Calculation of Compressed Header Size 

The following fields shall be excluded from the calculation of the size of the compressed header in evaluation of 
compression performance: 

• ROHC CID/add-CID octet(s) 

• ROHC padding octets 

• ROHC segmentation octets 

• ROHC feedback octets, either piggybacked on the behalf of an associated decompressor or as feedback 
packets interspersed within the flow of compressed packets 



B.2 Test Outline - RoHC RTP Profile 0x0001 

B.2.1 Test la - Base Test of ROHC RTP 0-Mode Compressor 



B.2. 1.1 Test Purpose 



The purpose of the base test case is to verify that the compressor properly implements compression for a well-behaved 
IP/UDP/RTP packet flow, i.e. that it makes use of efficient compressed packet formats available to ROHC RTP [5] 
when operating in O-mode. 
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B.2.1.2 Sequence Details 



A sequence consisting of 70 packets in total is used where all header fields are set according to the basic test packet 
structure, as described in clause B.3, with addition of the following: 

1) The RTP Sequence Number is a linearly increasing counter with a packet-to-packet delta of 1, set to 0x0000 
for the first packet and thus ending with 0x0045 (69) in the last packet of the sequence. 

2) The RTP Time Stamp is a linearly increasing counter with a packet-to-packet delta of 160, set to 0x00000000 
for the first packet and thus ending with 0x00002B20 (1 1040) in the last packet of the sequence. 

3) The IP Identification is set to the same value as the RTP Sequence Number; this means that for IPv4 the IP-ID 
behaviour is not random, thus value(RND)=0 defined in RFC 3095 [5] for both IPv4 and IPv6. 

Between the 6th and 7th packets (SN=5 and SN=6) of the sequence, a ROHC feedback packet of feedback type 2 is to 
be given to the ROHC compressor to trigger an immediate transition to O-mode operation. The format of that packet is 
as follows: 



01234567 

+ + + + + + + + + 

I 1 1 1 1 I Code I 
+ + + + + + + + + 



feedback type octet 



I Acktype | Mode 



SN 



+ + + + + + + + + 

I SN I 

+ + + + + + + + + 

|0 l|0 l| 

+ + + + + + + + + 

I CRC I 

+ + + + + + + + + 



Where: 



Code is set to 0x4 (indicates that feedback data above the type octet is 4 octets). 

Acktype is set to 0x0 (means ACK). 

Mode is set to 0x2 (means O-mode). 

SN is set to 0x000. 

CRC is the 8-bit CRC computed over the entire feedback payload including any CID fields but excluding the 
packet type, the 'Size' field and the 'Code' octet, using the polynomial defined in RFC 3095 [5]. 

NOTE: If compressor uses CID field in compressed packet, the CID field should be included in the feedback 
packet and the Code and CID should be set as defined in RFC 3095 [5]. 



B.2.1.3 Test Requirement 



Table B.2: Test Requirement for Test la 





Average Compressed 
Header Size, IPv4 


Average Compressed 
Header Size, IPv6 


SN < N + 1 


44 octets 


68 octets 


SN>N 


5 octets 


5 octets 



N is smaller than 8. 
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The sequence of expected compressed headers can be illustrated as follows (informative): 



Header Size 
(octets) 
IR — 
IR-DYN 



Feedback(ACK, mode=0x2, SN=OxOOO) 



N 7 



Figure B.I : Expected Outcome for Test la 



B.2.2 Test 1 b - Base Test of ROHC RTP R-Mode Compressor 
B. 2.2.1 Test Purpose 

The purpose of the base test case is to verify that the compressor properly implements compression for a well-behaved 
IP/UDP/RTP packet flow, i.e. that it makes use of efficient compressed packet formats available to ROHC RTP [5] 
when operating in R-mode. 

B. 2.2.2 Sequence Details 

A sequence consisting of 70 packets in total is used where all header fields are set according to the basic test packet 
structure, as described in clause B.3, with the addition of the following: 

1) The RTP Sequence Number is a linearly increasing counter with a packet-to-packet delta of 1, set to 0x0000 
for the first packet and thus ending with 0x0045 (69) in the last packet of the sequence. 

2) The RTP Time Stamp is a linearly increasing counter with a packet-to-packet delta of 160, set to 0x00000000 
for the first packet and thus ending with 0x00002B20 (1 1040) in the last packet of the sequence. 

3) The IP Identification is set to the same value as the RTP Sequence Number; this means that for IPv4 the IP-ID 
behaviour is not random, thus value(RND)=0 defined in RFC 3095 [5] for both IPv4 and IPv6. 

Between the 6* and 7* (SN=5 and SN=6) packet of the sequence, a ROHC feedback packet of feedback type 2 is to be 
given to the ROHC compressor to initiate transition to R-mode operation. The format of that packet is as follows: 

01234567 

+ + + + + + + + + 

I 1 1 1 1 I Code I feedback type octet 
+ + + + + + + + + 



I Acktype | Mode 



SN 



+ + + + + + + + + 

I SN I 

+ + + + + + + + + 

|0 l|0 l| 

+ + + + + + + + + 

I CRC I 

+ + + + + + + + + 



Where: 

• Code is set to 0x4 (indicates that feedback data above the type octet is 4 octets). 

• Acktype is set to 0x0 (means ACK). 
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Mode is set to 0x3 (means R-mode). 

SN is set to 0x000. 

CRC is the 8-bit CRC computed over the entire feedback payload including any CID fields but excluding the 
packet type, the 'Size' field and the 'Code' octet, using the polynomial defined in RFC 3095 [5]. 



B. 2.2.3 Test Requirement 



Table B.3: Test Requirement for Test lb 





Average Compressed 
Header Size, IPv4 


Average Compressed 
Header Size, IPv6 


SN < N + 1 


44 octets 


68 octets 


N<SN<8 


5 octets 


5 octets 


7 < SN < x+1 


9 octets 


9 octets 


SN > x+1 


5 octets 


5 octets 



N shall be smaller than 8. The value of x is the RTP SN for which the test equipment generates the first feedback 
message that corresponds to a packet with SN > 7, as described in clause B.1.4. 

The sequence of expected compressed headers can be illustrated as follows (informative): 



Header Size 
(octets) 

IR 

IR-DYN 

9 

5 



Feedback(ACK, mode=0x3, SN=OxOOO) 

Feedback(ACK, mode=0x3) 

L 



RTPSN 



Figure B.2: Expected Outcome for Test lb 

B.2.3 Void 

B.2.4 Void 

B.2. 5 Test 3a - Re-Establishment of TS Function after DTX in O- 
Mode 

B.2. 5.1 Test Purpose 

The purpose of the TS re-establishment test case is to verify that the compressor re-establishes the proper TS value after 
a DTX period, i.e. that it uses efficient header formats available to ROHC RTP [5] when operating in O-mode. 
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B.2.5.2 Sequence Details 

The test sequence is the same as in clause B.2.1, with the following exceptions: 

1) The RTP Time Stamp is a Unearly increasing counter with a packet-to-packet delta of 160, set to 0x00000000 
for the first packet. 

2) For packet with SN = 20, TS is increased to represent a 32 (0,64 seconds) packet skip (i.e. TS is increased by 
32 X 160) and is thus set to (20 + 32) x 160 = 8 320 (0x00002080). Then TS continues to grow as stated in 1, 
above. 

3) For packet with SN = 30, TS is increased to represent a 128 (2,56 seconds) packet skip (i.e. TS is increased by 
128 X 160) and is thus set to (30 + 32 + 128) x 160 = 30 400 (0x000076C0). Then TS continues to grow as 
stated in 1, above. 

4) For packet with SN = 40, TS is increased to represent a 2 048 (40,96 seconds) packet skip (i.e. TS is increased 
by 2 048 x 160) and is thus set to (40 +32+128 + 2 048) x 160 = 359 680 (0x00057D00). Then TS continues 
to grow as stated in 1, above. 

5) TS thus ends at 364320 (0x00058F20) in the last packet of the sequence with RTP sequence number 69. 



B.2.5.3 Test Requirement 



Table B.4: Test Requirement for Test 3a 





Average Compressed 
Header Size, IPv4 


Average Compressed 
Header Size, IPv6 


SN<20 


See Test 1a 


19<SN<20 + N 
29 < SN < 30 + N 


1 octets 


1 octets 


39 < SN < 40 + N 


1 octets 


1 octets 


Other SN values 


5 octets 


5 octets 



The sequence of expected compressed headers can be illustrated as follows (informative): 



Header Size 



(octets) 




TS jump(deltaTS=32x1 60 ) 




IR-DYN 


See 
Test la 


/ 




TS jump(deltaTS 


= 128x160) 

rs jump(deltaTS=2048x160 ) 

/ 














































RTPSN 



20 20 + N 30 30 + N 40 40 + N 



Figure B.3: Expected Outcome for Test 3a 



B.2.6 Test 3b - Re-Establisinment of TS Function after DTX in R- 
IVIode 

B.2.6. 1 Test Purpose 

The purpose of the TS re-establish test case is to verify that the compressor re-establishes the proper TS value after a 
DTX period, i.e. that it uses the efficient header formats available to ROHC RTP [5] when operating in R-mode. 
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B. 2.6.2 Sequence Details 

The test sequence is the same as in clause B.2.2, with the following exceptions: 

1) The RTP Time Stamp is a Unearly increasing counter with a packet-to-packet delta of 160, set to 0x00000000 
for the first packet. 

2) For packet with SN = 20, TS is increased to represent a 32 (0,64 seconds) packet skip (i.e. TS is increased by 
32 X 160) and is thus set to (20 + 32) x 160 = 8 320 (0x00002080). Then TS continues to grow as stated in 1, 
above. 

3) For packet with SN = 30, TS is increased to represent a 128 (2,56 seconds) packet skip (i.e. TS is increased by 
128 X 160) and is thus set to (30 + 32 + 128) x 160 = 30 400 (0x000076C0). Then TS continues to grow as 
stated in 1, above. 

4) For packet with SN = 40, TS is increased to represent a 2 048 (40,96 seconds) packet skip (i.e. TS is increased 
by 2 048 x 160) and is thus set to (40 +32+128 + 2 048) x 160 = 359 680 (0x00057D00). Then TS continues 
to grow as stated in 1, above. 

5) TS thus ends at 393 120 (Ox0005FFAO) in the last packet of the sequence with RTP sequence number 249. 



B.2.6.3 Test Requirement 



Table B.5: Test Requirement for Test 3b 





Average Compressed 
Header Size, IPv4 


Average Compressed Header 
Size, IPv6 


SN<20 


See Test 1 b 


19<SN<20 + x 
29 < SN < 30 + X 


1 octets 


1 octets 


39 < SN < 40 + X 


1 octets 


1 octets 


Other SN values 


5 octets 


5 octets 



The sequence of expected compressed headers can be illustrated as follows (informative): 



TS jump(deltaTS=32x1 60 ) 

/ TSjump(deltaTS=128x160) 

TS jump(deltaTS=2048x160 ) 




RTPSN 



20 20+x 30 30+x 40 40+x 



Figure B.4: Expected Outcome for Test 3b 



B.2.7 Test 4a - Compressor Response to Single Lost Packets in 
0-Mode 

B.2.7. 1 Test Purpose 

The purpose of this test is to verify that the compressor does not panic just because there is a single missing packet, i.e. 
the compressed packet size should not increase due to such events. 
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B. 2.7.2 Sequence Details 

The test sequence is the same as in clause B.2.1, with the following exception: 

• Packets with SN 20, 30, and 40 are removed from the sequence. 

B.2.7.3 Test Requirement 

Maximal compressed header overhead for the test are the same as in clause B.2.1. 

B.2.8 Test 4b - Compressor Response to Single Lost Packets in 
R-Mode 

B.2.8. 1 Test Purpose 

The purpose of this test is to verify the compressor properly handles a single missing packet, i.e. the compressed packet 
size should not increase due to such events. 

B. 2.8.2 Sequence Details 

The test sequence is the same as in clause B.2.2, with the following exception: 

• Packets with SN 20, 30, and 40 are removed from the sequence. 

B.2.8. 3 Test Requirement 

Maximal compressed header overhead for the test are the same as in clause B.2.2. 

B.2.9 Void 

B.2.1 Void 

B.2.1 1 Test 6a - TS Function During DTX with Varying Delta in O- 
Mode 

B. 2. 11.1 Test Purpose 

The purpose of this test case is to verify that the compressor properly handles variations in the function between the TS 
value and the SN during and after a DTX period, during which SID packets are sent periodically, i.e. that it uses 
efficient header formats available to ROHC RTP [5] when operating in O-mode. 

B.2.1 1.2 Sequence Details 

The test sequence is the same as in clause B.2.1, with the following exceptions: 

1) The RTP Time Stamp is a linearly increasing counter with a packet-to-packet delta of 160, set to 0x00000000 
for the first packet. 

2) For packets SN = 20, 21 and 22, TS is increased to represent a 7 (0,14 seconds) packet skip (i.e. TS is 
increased by 7 x 160) and is thus set to (20 H- 7) x 160 = 4 320 (0x0000 lOEO), 

(21 H- 7 H- 7) X 160 = 5 600 (OxOOOOlSEO) and (22 h- 7 h- 7 h- 7) x 160 = 6 880 (OxOOOOlAEO), respectively. 
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3) For packets SN = 30, 31, 32, 33 and 34, TS is increased to represent a 7 (0,14 seconds) packet skip (i.e. TS is 
increased by 7 x 160) and is thus set to 9 280 (0x00002440), 10 560 (0x00002940), 11 840 (0x00002E40), 
13 120 (0x00003340) and 14 400 (0x00003840), respectively. 

4) For packets SN = 40, 41, 42, 43, 44, 45, and 46, TS is increased to represent a 7 (0,14 seconds) packet skip 
(i.e. TS is increased by 7x160) and is thus set to 16 480 (0x00004060), 17 760 (0x00004560), 19 040 
(0x00004A60), 20 320 (0x00004F60), 21 600 (0x00005460), 22 880 (0x00005960) and 24 160 (0x00005E60), 
respectively. 

5) TS thus ends at 27 840 (0x00006CC0) in the last packet of the sequence with RTP sequence number 69. 

B.2.1 1 .3 Test Requirement 



Table B.6: Test Requirement for Test 6a 





Average Compressed 
Header Size, IPv4 


Average Compressed Header 
Size, IPv6 


SN<20 


See Test 1 a 


19<SN<23 + N 
29 < SN < 35 + N 
39 < SN < 47 + N 


1 5 octets 


1 5 octets 


Other SN values 


5 octets 


5 octets 



The sequence of expected compressed headers can be illustrated as follows (informative): 



Header Size 
(octets) 

IR 



IR-DYN - 

16- 



See 
Test 1 a 



TSjump(deltaTS=7x160) 

TSjump(deltaTS=7x160) 

TSjump(deltaTS=7x160) 




RTPSN 



20 1 22 22+N 30 I 32 I 34 34+N 40 I 42 I 44 I 46 46+N 
21 31 33 41 43 45 



Figure B.5: Expected Outcome for Test 6a 



69 



B.2.1 2 Test 6b - TS Function During DTX with Varying Delta in R- 
Mode 

B.2.1 2.1 Test Purpose 

The purpose of this test case is to verify how efficiently the compressor handles variations in the function between the 
TS value and the SN during and after a DTX period, during which SID packets are sent periodically; i.e. that it uses the 
efficient header formats available to ROHC RTP [5] when operating in R-mode. 

B.2.1 2.2 Sequence Details 

The test sequence is the same as in clause B.2.2, with the following exceptions: 

1) The RTP Time Stamp is a linearly increasing counter with a packet-to-packet delta of 160, set to 0x00000000 
for the first packet. 

2) For packets SN = 20, 21 and 22, TS is increased to represent a 7 (0,14 seconds) packet skip (i.e. TS is 
increased by 7 x 160) and is thus set to (20 H- 7) x 160 = 4 320 (0x0000 lOEO), 

(21 H- 7 H- 7) X 160 = 5 600 (0x0000 15E0) and (22 h- 7 h- 7 h- 7) x 160 = 6 880 (0x0000 lAEO), respectively. 
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3) For packets SN = 30, 31, 32, 33 and 34, TS is increased to represent a 7 (0,14 seconds) packet skip (i.e. TS is 
increased by 7x160) and is thus set to 9 280 (0x00002440), 10 560 (0x00002940), 1 1 840 (0x00002E40), 

13 120 (0x00003340) and 14 400 (0x00003840), respectively. 

4) For packets SN = 40, 41, 42, 43, 44, 45, and 46, TS is increased to represent a 7 (0,14 seconds) packet skip 
(i.e. TS is increased by 7 x 160) and is thus set to 16 480 (0x00004060), 17 760 (0x00004560), 19 040 
(0x00004A60), 20 320 (0x00004F60), 21 600 (0x00005460), 22 880 (0x00005960) and 24 160 (0x00005E60), 
respectively. 

5) TS thus ends at 27 840 (0x00006CC0) in the last packet of the sequence with RTP sequence number 69. 

B. 2.1 2.3 Test Requirement 

Table B.7: Test Requirement for Test 6b 





Average Compressed 
Header Size, IPv4 


Average Compressed Header 
Size, IPv6 


SN<20 


See Test 1 b 


19<SN<23 + x 
29 < SN < 35 + X 
39 < SN < 47 + X 


1 5 octets 


1 5 octets 


Other SN values 


5 octets 


5 octets 



The sequence of expected compressed headers can be illustrated as follows (informative): 



Header Size 
(octets) ■' 

IR - 



16- 



See 
Test lb 



TSjump(deltaTS=7x160) 

TSjump(deltaTS=7x160) 

TSjump(deltaTS=7x160) 



20 1 22 22+x 30 1 32 1 34 34+x 40 1 42 1 44 1 46 46+x 

21 31 33 41 43 45 



Figure B.6: Expected Outcome for Test 6b 



B.2.13 Test 7a - SRNS Relocation in 0-Mode 

SRNS Relocation for RoHC is Not supported in this version of GMR-1 3G. 

B. 2.1 3.1 Test Purpose 

Void. 

B. 2.1 3.2 Sequence Details 

Void. 

B. 2.1 3.3 Test Requirement 

Void. 



RTPSN 
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B.3 Test Packet Structures 

IPV6/UDP/RTP 

12 3 

01234567890123456789012345678901 

I Version I Traffic Class | Flow Label | 

I Payload Length | Next Header | Hop Limit | 



Source Address 



+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 



Destination Address 



I Source Port | Destination Port | 

I Length | Checksum | 

|V=2|P|X| CC |m| PT I sequence number | 

+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 
I timestamp | 

I synchronization source (SSRC) identifier | 
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IPV4/UDP/RTP 

12 3 

01234567890123456789012345678901 

I Version I IHL | Type of Service | Total Length | 

I Identification |r|d|f| Fragment Offset | 
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 

I Time to Live | Protocol | Header Checksum | 

I Source Address | 

I Destination Address | 

I Options I Padding | 

I Source Port | Destination Port | 

I Length | Checksum | 

|V=2|P|X| CC |m| PT I sequence number | 

I timestamp | 

I synchronization source (SSRC) identifier | 



IPv6 header fields 

+ 

I Field 



- + + ■ 

I Size (bits) I 



Value 



Version 
Traffic Class 
Flow Label 
Payload Length 
Next Header 
Hop Limit 
Source Address 
Destination Address 



1 4 


0x6 1 


1 8 


0x00 1 


1 20 


0x00000 1 


1 16 


0x0034 1 


1 8 


0x11 1 


1 8 


Test dependent 


128 


ANY 


1 128 


ANY 1 



ader fields 










+ 


+ -- 




Field 


Size 


(bits) 1 


Value 




+ 


+ __ 





Version 

Header Length (IHL) 
Type Of Service 
Packet Length 
Identification 
Reserved flag (R) 
Don't Fragment (D) 
More Fragments (F) 
Fragment Offset 
Time To Live 
Protocol 
Header Checksum 
Source Address 
Destination Address 



1 4 


0x4 


1 4 


0x5 


1 8 


0x00 


1 16 


0x0048 


1 16 


Test dependent 


1 


0x0 


1 1 


0x1 


1 1 


0x0 


1 13 


0x0000 


1 8 


Test dependent 


8 


0x11 


1 16 


See RFC 791 


1 32 


ANY 


1 32 


ANY 
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UDP header fields 

+ 

I Field 



. + + . 

I Size (bits) I 



Source Port 
Destination Port 
Length 
Checksum 



16 
16 
16 
16 



Value 



ANY 
ANY 
0x0034 
See RFC 76! 



RTP header fields 



Field 



Version (V) 
Padding (P) 
Extension (X) 
CSRC Counter 
Marker (M) 
Payload Type 
Sequence Number 
Time St amp 
SSRC 



- + + ■ 

I Size (bits) I 



Value 





2 


0x2 




1 


0x0 




1 


0x0 


(CO 


4 


0x0 




1 


0x0 


(PT) 


7 


0x60 


er 


16 


Test dependent 




32 


Test dependent 




32 


ANY 
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Annex C (informative): 

Reference IVIodel for Generating ROHC Performance 

Requirements 



C.1 Introduction 



ROHC compressor and decompressor may use a set of parameters in order to operate (e.g. L confidence parameter, 
dynamic FOtimer and static IRtimer, Kl out of Nl, K2 out of N2. . .) that may be optimised for a given application 
(e.g. Voice over IP, Videotelephony over IP, Interactive Gaming over IP). 

NOTE: L confidence parameter allows setting the number of times an IR or IR-Dyn packet is transmitted and 
FOtimer and IRtimer are used in order to determine when a transition to a lower compressor state is 
necessary: The dynamic timer FOtimer triggers SO state to FO state transition and the static IRtimer 
triggers SO/FO state to IR state transition. 



C.2 For Voice-over-IP (VoIP) Optimisation 
C.2.1 ROHC Parameters Optimisations for VoIP 

For the support of VoIP in the network, ROHC compressor and decompressor parameter values (L confidence 
parameter, dynamic FOtimer and static IRtimer, Kl out of Nl, K2 out of N2) may be used. Values used in ROHC 
reference model are given in clause C.2. 2 for O-mode. 

The initialization phase duration 

The reaction delay to decompression failure 

The header compression ratio (compressed header size/uncompressed header size) 

The error rates (in UDP and PDCP layers) 

The amount of transferred data (including ROHC compressed packets and feedbacks) 

The resource usage (transport block occupancy in the RLC layer) 

C.2.2 Parameter Setting for ROHC Reference IVIodel for VoIP 

The following parameters setting is applied in the reference model for ROHC performance tests of VoIP application: 

Table C.I : ROHC Parameters Setting for VoIP 



ROHC Parameter 


0-Mode 


L 


2 


FOtimer 


0,12 seconds 


IRtimer 


0,12 seconds 


K1 /N1 


2/20 


K2/N2 


1 /I 
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C.2.3 Setting the Parameter Value N in Test Cases for VoIP 

In test cases for VoIP to evaluate ROHC Compression performance for both O- and R-mode, the parameter N (defined 
in Annex A) is set to 4. 
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Annex D (normative): 
Data Compression 

D.1 Overview 

V.44 data compression used in PDCP has two main parts: control function and data compression function. 













To 

^Upper 

layer 


ToHC -^ — ► 


Control Function 


^^_uaia^ 

Command 
(L-NAIVlE_type) 






^^ ^^ Command " 
data (C-NAME type) 




Data Compression/ 
decompression 





Figure D.I: V.44 Data Compression Functional Blocl<s 

Control function in V.44 data compression communicates with the external entities, for example error control function, 
for command, and data transfer, as well. Data compression function encodes or decodes data. 



D.2 Control Function 



Refer to ITU-T Recommendation V.44 [8]. 



D.3 Data Compression Function 



The data compression function consists of an encoder and a decoder. The encoder transfers the compressed data to 
decoder at the other end of the connection. Since most communication systems support bidirectional data transfer, each 
communicating party will typically have both an encoder and a decoder. Furthermore, in a case where one of the parties 
might have more resources, for example RNC can have more resources than MES, the compression might not be 
symmetric, i.e. the RNC to MES direction might have a better compression than the MES to RNC direction. 



D.3.1 Encoding 



Refer to ITU-T Recommendation V.44 [8] for encoding operation. 

If the encoder cannot compress the data, it shall forward the data unchanged to the Header Compression entity. The 
encoder shall compare the size of the encoder output to the size of the input to see whether the compression was 
successful or not. If the output size of the encoder is larger than the input size, then the compression is considered to 
have failed and the data shall be forwarded unchanged. 

D.3.2 Decoding 

Refer to ITU-T Recommendation V.44 [8] for decoding operation. 

For uncompressed binary codes, the decoder does not do any decoding; it simply forwards it to upper layer through the 
control function. 
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D.4 Packet Technique and Multi-Packet Technique 

V.44 can operate in two different techniques: Packet Technique and Muhi-Packet Technique. In packet mode, each 
packet is processed independently. 

Packet Technique is also called stateless mode. Packet Technique and stateless mode will mean the same thing in the 
present document. 

In Multi-Packet Technique, several packets or portion of packets are processed as a continuation. Multi-Packet 
Technique and stateful mode will mean the same thing in the present document. 

The main differences between Packet Technique and Multi-Packet Technique are summarized in Table D.l. 
Table D.l : Packet Mode and Multi-Packet Mode Differences 



Packet Mode 


Multi-Packet Mode 


Does not require guaranteed delivery 


Requires guaranteed delivery 


Encoder and decoder dictionaries are initialized every 
packet 


Encoder and decoder dictionaries are initialized at the 
beginning or if control function requests 
re-initialization 


Encoder and decoder histories are not required 


Encoder and decoder require histories 



Multi-packet mode provides better compression with the expense of higher complexity compared to Packet mode. 

Since Packet/Multi-Packet Technique does not support transparent mode if the encoder fails, it shall send the original 
(uncompressed) data with the first bit of the PDU type set to to indicate that the data is not compressed and the 
dictionary needs to be reset, see clause 8.3.1. 

For the GMR-1 3G LLA Header Suppression SE-VoIP case, the packet will not go through the data compression 
function. When packets arrive at PDCP layer, there shall be screening that checks the type of packet. For packets 
classified as SE-VoIP, there shall be no data compression. 



D.5 Transfer 



Refer to ITU-T Recommendation V.44 [8]. 



D.6 Communication between Control Function and Data 
Compression Function 

Refer to ITU-T Recommendation V.44 [8]. 

D.7 Communication between Peer Data Compression 
Function 

Refer to ITU-T Recommendation V.44 [8]. 



D.8 Configuration Parameters 



The encoder and decoder shall agree on a set of parameters to be able to function properly. These parameters can be 
negotiated. However, in order to simplify the procedures, a set of default parameters should be configured on encoder 
and decoder. 
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Since the RNC has more resources than the MES, the configurations for the RNC-to-MES direction and the 
configuration for the MES-to-RNC direction are not the same. Tables D.2 and D.3 show the default configuration RNC- 
to-MES and the default configuration for MES-to-RNC respectively. 



Table D.2: Data Compression Parameters: RNC-to-MES 



Parameters 


Default Values 


Description 


N2 (N2T = N2r) 


1 525 


Total number of codewords (node-tree) or string of consecutive 
characters, greater than the maximum length packet expected, in 
bytes 


N7(N7T=N7r) 


255 


Maximum string length 


N8(N8T=N8r) 

(Note 1) 


4xN2 


Length of history, aggregation of Na and N2 if possible to achieve 
better compression, in bytes 


Ni 


Derived from N2 


IVIaximum codeword size in bits 


N4 


256 


Number of characters in alphabet 


N5 


4 


Number of control code and first available codewords 


Ci 


Ns 


Initial values 


C2 


6 


Initial current codewords size bits 


C3 (Note 2) 


64 


Initial threshold for changing codewords size in bits, 2'^- 


C4 





Initial "current history position" 


Cs 


7 


Initial current ordinal size in bits 


NOTE 1 : For Packet Technique Ns is not applicable. 
NOTE 2: Only for encoder. 


Table D.3: Data Compression Parameters: MES-to-RNC 


Parameters 


Default Values 


Description 


N2 (N2T = N2r) 


1 525 


Total number of codewords (node-tree), greater than the maximum 
length packet expected, in bytes 


N7(N7T=N7r) 


255 


IVIaximum string length 


Na (NaT = NaR) 
(Notel) 


2xN2 


Length of history, aggregation of Na and N2 if possible to achieve 
better compression, in bytes 


Ni 


Derived from N2 


l\/laximum codeword size in bits 


N4 


256 


Number of characters in alphabet 


N5 


4 


Number of control code and first available codewords 


Ci 


N5 


Initial values 


C2 


6 


Initial current codewords size bits 


C3 (Note 1 ) 


64 


Initial threshold for changing codewords size in bits, 2^^= 


C4 





Initial "current history position" 


C5 


7 


Initial current ordinal size in bits 


NOTE 1 : For Packet Technique N8 is not applicable. 
NOTE 2: Only for encoder. 



For each pair of MES-RNC compression/decompression, there are only two types of context created for each RAB: one 
for TCP and one for UDP. This means that all TCP flows shall go to the TCP context, and all UDP flows shall go to the 
UDP context. For example, if a MES open Web browser session in which a RAB will be created and there are several 
TCP flows opened for this RAB, only one TCP context shall be created to cater for all the TCP flows for that RAB. 
Similarly, one UDP context shall be created for all the UDP flows. 



ETSI 



GMR-1 3G 25.323 58 ETSI TS 101 376-4-15 V3.3.1 (2012-12) 



Annex E (informative): 
Bibliography 



ETSI TS 125 303: "Universal Mobile Telecommunications System (UMTS); Interlayer procedures in Connected Mode 
(3GPP TS 25.303 Release 7)". 

IETF RFC 3096: "Requirements for robust IP/UDP/RTP header compression". 

IETF RFC 4362: "RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP". 

IETF RFC 3408: "Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted 
RObust Header Compression (ROHC) Profile". 

ETSI TS 101 376-4-13: "GEO-Mobile Radio Interface Specifications (Release 3); Third Generation Satelhte Packet 

Radio Service; Part 4: Radio interface protocol specifications; 

Sub-part 13: Radio Resource Control (RRC) protocol; lu Mode; GMR-1 3G 44. 1 18". 

ETSI TS 101 376-4-14: "GEO-Mobile Radio Interface Specifications (Release 3); Third Generation Satelhte Packet 
Radio Service; Part 4: Radio interface protocol specifications; 

Sub-part 14: Mobile Earth Station (MES) - Base Station System (BSS) interface; Radio Link Control/Medium Access 
Control (RLC/MAC) protocol; lu Mode; GMR-1 3G 44.160". 

ETSI TS 101 376-4-12: "GEO-Mobile Radio Interface Specifications (Release 3); Thkd Generation Satelhte Packet 
Radio Service; Part 4: Radio interface protocol specifications; 

Sub-part 12: Mobile Earth Station (MES) - Base Station System (BSS) interface; Radio Link Control/Medium Access 
Control (RLC/MAC) protocol; GMR-1 3G 44.060". 

ETSI TS 125 323: "Universal Mobile Telecommunications System (UMTS); Packet Data Convergence Protocol 
(PDCP) specification (3GPP TS 25.323 Release 7)". 



£75/ 



GMR-1 3G 25.323 



59 



ETSI TS 101 376-4-15 V3.3.1 (2012-12) 



History 



Document history 


V3.3.1 


December 2012 


Publication 



























£75/ 



